微服务架构基本介绍与微服务设计模式

微服务与传统单体服务

单体服务

一个项目中包含了所有的服务叫做单体服务

优点：

开发简单，对技术栈要求不高
部署、运维方便，只需要对一台机器、一个服务进行部署、运维
服务监控、问题排查简单，只需要对一台机器的监控与日志分析

缺点:

可以对多个模块化组件的整体JVM进程进行水平扩展，而无法单独对某个模块化组件进行水平扩展
当仅修改某个模块时，需要所有模块进行编译、打包和上线
模块间相互依赖、相互耦合

微服务

微服务是把每一个职责单一的功能放在独立的服务中，且每个服务运行在一个单独的进程中，每个服务都有自己的数据存储（如缓存、消息队列）

优点：

每一个服务可以有多个实例，当运行在容器化的平台，可以平滑伸缩
资源的有效隔离：每一个微服务拥有独立的数据资源，服务间调用只能通过暴露的接口来完成
团队组织架构的调整：可以根据不同服务让不同的小组负责，分工明确

缺点：

微服务把原有的项目拆分成多个独立工程，增加了开发、测试、运维、监控等的复杂度。
微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战

微服务与SOA区别

SOA（面向服务的架构）：SOA是一个组件模型，将不同功能单元通过定义好的接口和契约进行关联。使得构建在各种各样的系统中的服务可以以一种统一和通用的方式交互。

微服务：将一个单体应用作为一套小型服务开发的方法，每个服务都在自己的进程中运行。同行使用轻量级（通常是HTTP）机制通信。每个服务可以使用不同的编程语言编写，并使用不同的数据存储技术。

区别如下：

	SOA服务	微服务
目标	强调异构服务之间协作和集成	拆分模块、快速拓展开发团队
管理	着重中央管理理	重在分散管理理
粒度	通常粒度粗	拆分粒度更更细，职责单⼀
通信	ESB企业服务总线	HTTP（REST API）
划分	前、后端、数据库、测试等类别划分	业务边界做细粒度的拆分

六种常见微服务架构设计模式

聚合器微服务设计模式

类似于数据库中的聚合查询一样，聚合器调用多个服务实现应用程序所需的功能。
它可以是一个web页面，将所有微服务的数据进行处理后展示；也可以是对多个微服务进行组合，发布成为一个新的微服务（符合DRY（Don’t Repeat Yourself）原则）

代理理微服务设计模式

代理和聚合的主要区别是：代理不做聚合数据，仅仅做代理。
代理模式会根据需求的差别调用不同的微服务，代理可以仅仅做请求委派，也可以对数据进行转换

链式微服务设计模式

各种服务之间具有逻辑上的执行顺序，需要串行操作

在这种情况下，服务A（SA）接收到请求后会与服务B通信，服务B会与服务C通信。所有服务都是用同步消息传递。在整个链式调用结束之前，客户端会一致阻塞等待响应，因此服务调用链不宜过长，避免客户端长时间等待。

分支微服务模式

SA服务的分支为SB、SC两个服务，也就意味着SA可以与SB、SC两个服务进行交互，很多的业务模型可以通过此模型进行处理

数据共享微服务设计模式

在单体应⽤用到微服务架构的过渡阶段，可以使⽤用这种设计模式

在这种情况下，部分微服务可能会共享缓存和数据库存储。不过只有在两个服务间存在强耦合关系才可以。

异步消息传递微服务设计模式

虽然REST规范非常流行，但它是同步的，会造成客户端阻塞。因此部分基于微服务的架构可能会选择使用消息队列来代替REST的请求/响应，因为消息队列可以是异步的。

如图可知，SA、SB、SC之间通过消息队列进行异步消息通信，服务之间不需要等待请求结束

除了以上几种微服务设计模式，我们还可以基于几种基础的设计模式进行组合，如分叉+链式组合、链式+异步消息传递组合等

SpringCloud

Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的⼯具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。
分布式系统的协调板模式, 使用SpringCloud开发人员可以快速地支持实现这些模式的服务和应用程序

SpringCloud微服务的生态圈

微服务技术栈	实现技术
服务开发	SpringBoot, SpringMVC
服务配置	Config
服务注册与发现	Eureka
服务调用	Ribbon, Feign
服务路由	Zuul
服务熔断	Hystrix
服务全链路监控	Sleuth + Zipkin
服务部署	Docker、K8s

SpringCloud的技术栈应用

基本过程：

客户端发送请求后，经过网关Zuul、熔断器Hystrix、负载均衡器Ribbon/Feign
然后请求会被负载均衡器发送到某一个服务
服务中会根据配置中心的配置对请求进行处理
调用过程中，调用链监控Sleuth+Zipkin会对服务全链路进行监控

这边有一个服务注册中心集群，它是负责所有服务的管理，比如网关、熔断器、订单服务等对于注册中心来说都是客户端，而注册中心就是服务端。图中由三个Eureka注册中心组成一个集群，它们各自拥有者对方的副本(Replicas)。

微服务实践思考

微服务如何合理拆分？

把当前所有的服务列举出来，拿着清单和产品去对，比如产品未来规划、走向，如未来3年或5年的要求
梳理服务中所有的东西，服务需要拆的粒度、服务的边界值，这些最好是大家一起定
数据库是每一个微服务都有一个库，还是有区分主库、从库？
业务量的大小，需要多少服务器资源、需要承受多大的并发量

服务拆分也是微服务中比较难的一块，需要考虑的东西较多。

单体服务如何平滑过渡到微服务？

评估当前代码是否需要调整？如果模块之间耦合性高，则调整可能性就很高
服务的分类，哪些是核心服务、哪些是重量服务，服务之间的优先级是怎么样的？
服务拆分先从边界业务开始拆分，然后慢慢靠近核心服务。
边拆边上线，根据经验，一般拆需要1~2年， 3年稳定
中间件是否符合需求、部署、运维等多方面考虑
微服务也涉及到了架构调整，那么多份代码需要合并，多久合并一次？如何合并？都是需要考虑的

当以上都清楚了，你就可以开始着手进行重构了

微服务架构如何正确复盘？

架构选型是否符合未来的几个服务
未来服务扩容是否没问题？
运维成本是否增加了？
拆解完成后微服务是如何管理的？是所有人都有权限管理还是有专人负责管理微服务？

无论什么事情，我们都需要复盘，优化过程与总结经验

参考

springcloud中文教程