分布式+微服务架构

1、分布式+微服务架构随着互联网技术的飞速发展，目前全球超过半数以上的 人口在使用互联网，人们的生活、工作随着互联网的发展， 发生了翻天覆地的变化。我们的工作随着越来越多的用户参 与，业务场景越来越复杂，云计算、大数据、区块链、人工 智能的飞速发展对系统架构也提出了越来越高的要求，我们 原来使用的单体架构已经不能满足工作场景需求。此时 Martin Fowler提出来了微服务架构，一个分布式系统架 构，按业务领域划分为独立的服务单元，满足越来越复杂的 业务需求，并且可以自动化运维、容错、快速演进。微服务 是“互联网+时代”催生的一种设计思想和理念。一、技术架构的前生今世1、单体架构单体架构将系统中

2、的所有功能、模块耦合在一个应用中 的架构方式。如MVC架构，表示层（View）+中间业务逻 辑层（Controller）+数据库层（Model）。代表技术 Spring mvc、Struts2等。该架构具有以下特点：复杂性高、项目包含的模块非常多、模块的边界模 糊、依赖关系不清晰，随着业务复杂度的提高，代码的可 维护性、扩展性和可读性在降低。可靠性差、某个模块的问题（内存溢出）可能会导 致整个系统的崩溃。扩展能力受限、该构架只能作为一个整体进行扩 展，无法根据业务模块的需要进行伸缩。易运维、项目可以直接打成亚包发布。2、SOA架构（面向服务）SOA架构属于企业领域，将原来的单体架构按照功能分为

3、 不同的子系统，然后再由各个子系统依赖服务中间件来调用 所需服务。服务之间采用webservice、rpc等方式进行通 信，5。人大部分概念是基于企业服务总线（ESB）的，即企业 服务总线作为服务之间通信的桥梁。该架构具有以下特点：重用性、重复的功能抽取为服务，提高开发效率， 提高系统的可重用性。针对不同服务的特点制定集群及优化方案。服务的颗粒度大。SOA强调ESB企业服务总线。为了集成不同系统， 不同协议的服务，ESB做了消息的转换解释与路由等工作， 让不同的服务互联互通。3、微服务架构应用程序划分成一组小的服务，每个服务都围绕着具体 业务进行构建，每个服务运行独立的自己的进程中，能够被 独

4、立地部署到生产、测试环境。服务之间互相协调、互相配 合，服务之间采用轻量级的通信机制互相沟通（通信是基于 HTTP的RESTful API）为用户提供最终价值。与SAO架构相比，不存在一个企业服务总线调度，而是各个服务之间自主发现和调用其它服务，且可以是跨终端跨平台的调用。SpringCloud提供了一站式微服务解决方案：二、开发框架我司目前采用前后端分离开发框架、前端采用Vue框 架，后端采用SpringCloud微服务架构。三、框架名词解释说明前后端分离、前端静态代码部署在Apache Server 服务器与后端服务只进行数据交互，所有的页面展现、切换 都在前端完成（jsp运行在web服务

5、器端），响应时间短用 户体验更好。前端采用Vue框架，Vue是一个轻量级、高性 能构建用户界面的渐进式框架，具有数据双向绑定（MVVM）、组件化等特点；后端采用SpringCloud微服务架 构进行开发，每个微服务单独部署、独立运行对外提供接 口。前后端开发按照接口文档约定各自为战。Nginx、反向代理功能，客户不想让外部人员看自 己的内部，就需要网关来进行反向路由，即将外部请求转换 成内部具体服务调用。负载均衡功能、采用权重等策略对 Gateway集群做负载均衡。Eureka、Eureka Server服务注册功能的服务器， 它是服务注册中心。系统中的其他微服务使用Eureka的客 户端（E

6、ureka Client）注册、连接至1Eureka Server， 维持心跳连接。可以通过Eureka Server来监控系统中各 个微服务是否正常运行。服务消费方从Eureka Server获取 注册服务列表，从而能够消费服务，服务消费方可以设置负 载均衡，默认策略为轮询。Gateway、我司采用Zuul网关、该网关有路由和过 滤两个功能。路由功能实现外部访问统一入口，负责将外部 请求转发到具体的微服务实例。过滤功能指对请求的处理过 程进行干预,实现请求校验（登录验证）等功能。AuthService、认证中心。在Gateway登录验证未 通过的请求，必须去认证中心采用用户名、密码方式进行登

7、 录认证。认证通过后AuthService会给客户颁发令牌，再次 访问时客户带着令牌访问即可。Sentinel、流量监控及服务熔断、降级。应用流量的QPS （每秒请求数量）或并发线程数等指标达 到指定阈值时对流量进行控制，避免系统被瞬时的流量高峰 冲垮，保障应用高可用性。如果调用链路中的某个资源不稳定，最终会导致请求发 生堆积。Sentinel熔断降级会在调用链路中某个资源出现 不稳定状态时（例如调用超时或异常比例升高），对这个资 源的调用进行限制，让请求快速失败，避免影响到其它的资 源而导致级联错误。当资源被降级后，在接下来的降级时间 窗口之内，对该资源的访问都自动熔断。熔断后可以采用消 息

8、队列方式对业务数据进行补偿。四、架构特点以使用服务的方式来实现组件化。每个服务独立构 建、部署（避免了对整个系统的一个小地方的改动，都要对 整个系统重新构建，部署的问题）、独立运行、可以独立数 据库、针对服务按需收缩，根据需求实现细粒度的扩展。（例如系统中的某个微服务遇到了瓶颈，可以结合这个微服 务的业务特点，增加内存、升级CPU或者增加节点）单个微服务易于开发和维护（擅长的人干擅长的 事），服务内高内聚、服务间低耦合。持续交付、统一监控。做产品不是做项目，基于“谁构建，谁运行”的理 念，与做项目的核心区别在于，做完了项目就交付给运维去 运维，然而做产品意味着，开发要在产品的整个生命周期中 承担一些运维职责。可以增进开发、运维、客户之间的交流 沟通。发开成本高、测试的复杂性（系统集成测试）、运 维的复杂性。多服务、跨数据库访问的数据一致性。服务间通信成本。系统设计层面如何服务拆分达到最优效果。五、DevOpsDevOps是一种软件开发方法，涉及软件在整个开发生命 周期中的持续开发，持续测试，持续集成，持续部署和持续 监控。用于促进开发、运营和质量保障（QA）部门之间的 沟通、协作与整合；强调共同对业务目标负责，以实现用户 价值作为唯一的评判标准：保证产