【备战春招】第21天+微服务架构的落地

课程名称：DDD（领域驱动设计）思想解读及优秀实践

课程章节： 战术设计

课程讲师： 尤达_技术咖啡

1. 微服务架构的落地需要解决服务治理问题，而服务治理依赖良好的底层方案。当前，微服务的底层方案总的来说可以分为两种：微服务SDK（微服务框架）和服务网格。微服务框架运行原理：应用程序通过接入SDK来实现服务治理，SDK运行在应用程序的上下文（相同进程），构建后成为应用程序的一部分。服务网格运行原理：通过Sidecar模式，用单独的代理进程接管应用程序的网络流量，从而实现服务治理，借助代理进程，可以实现服务的流量控制（访问权限控制、限流、熔断等等）、服务发现、负载均衡等等服务治理相关功能。1

2. 一.微服务框架1.SpringBoot+SpringCloudSpringBoot是最流行的Java应用框架，而SpringCloud是面向微服务治理的不同需求的一整套框架的集合，或者说框架的规范（而且是弱规范，之所以说只能称为弱规范，因为同一个问题，SpringCloud中有不同的框架来解决，而且从一种切换到另一种，需要修改代码，比如说Hytrix和Sentinel，流行的全家桶也从SpringCloudNetflix过度到了SpringCloudAlibaba等等）。可以认为SpringCloud是SpringBoot的扩展，铁打的SpringBoot，流水的SpringCloud扩展。2.GoMicrogomicro是一个基于可插拔式RPC的底层库，提供用go语言写微服务的各种构造块。gomicro使用consul实现服务发现，通信基于http，编码则使用proto-rpc，json-rpc，并且提供发布/订阅模式。gomicro致力于解决建立可伸缩系统的关键性问题，它把微服务架构模式拆解并转换成了一组工具集，能够解决分布式系统中的复杂性问题，并且向程序员提供易于理解的简单抽象。**API网关：**microapi通过服务发现能够提供强大的路由功能和可插拔的处理器，以处理http,grpc,websockets等协议请求。**交互式客户端：**通过交互式客户端提供的命令，可以清楚地了解系统中各个微服务发生了什么。**服务代理：**基于gomicro和MUCP协议构建的透明服务代理，提供应用无关的服务发现、负载均衡、消息编解码、熔断器等等插件。可以独立部署也可以和服务并肩部署。**服务模板：**提供内置的服务模板快速创建新服务。SlackOpsBot:一个运行在用户平台上的机器人，让你可以从Slack管理你的应用。**Web控制台：**通过web控制台，可以观察服务的情况，描述服务的访问入口，查看请求和响应的格式，甚至直接请求服务。3.Molecular一个面向NodeJS的服务框架。支持基于NodeJS构建高效、可靠、可伸缩的服务。4.QuarkusRetHat开发的一款比较新的Java框架，对k8s和云原生支持比较好，是Kubernetes上原生的Java框架，它的目标是让Java语言变成Kubernetes上的第一语言。5.LagomLagom是一款用Java和Scala构建响应式微服务的开源框架，Lagom本身基于Akka和Play开发。Lagom的集成开发环境可以让开发者集中精力解决业务问题，而不用过于关心怎么把服务组装在一起。一个命令就可以构建整个项目，启动支撑组件、Lagom的微服务框架、以及开发者的微服务本身。当服务检测到代码变化时，可以自动热加载。6.AxonAxon是一款面向DDD和事件驱动架构的服务框架。Axon包含一套编程模型以及支撑这套模型的基础设施，Axon包括Axon框架和AxonServer，其中Axon框架提供编程模型而AxonServer提供基础设施部分。Axon是开源的。二.服务网格IstioIstio是服务网格技术的主流实现，它为Kubernetes提供了一组扩展，借助其中的Envoy服务代理能够无侵入（弱侵入）地提供服务的流量管理、遥测技术、安全管控等等重要的服务治理能力。Istio服务网格由控制平面和数据平面构成。控制平面的核心组件是Pilot和

微服务拆分原则
在进行微服务拆分的过程中，有几条笔者总结的原则大家可以参考下，在实操的时候如果没有原则来遵循，实际我们自己也没办法去评判微服务拆分的效果到底有没有达到我们的预期。

微服务拆分要把握度
如果在微服务拆分过程中发生过度拆分，就会导致微服务爆炸的情况。不可避免的增加软件系统的维护成本，同时由于拆分也会导致业务流程变长，原本一两个服务就完成的业务，拆分后需要在五六个甚至更多的微服务才能完成，增加了平台出现 Bug 的概率，不知不觉中降低了平台的稳定性。另外更多的微服务意味着需要更多的服务器资源，从而在无形中增加了业务成本。因此我们可以借助于 DDD 划分的边界上下文，防止微服务过度拆分情况的发生。

拆分过程逐步迭代
软件平台架构的演进过程必定会经历现有平台以及新架构平台先共存，后替代的过程。因此我们可以先从平台的非核心功能开始再到核心功能这样逐步拆分的方式进行迭代拆分，避免一上来就要大刀阔斧的进行微服务拆分以及架构调整，否则就会陷入旧平台不稳定而新平台又不完善的尴尬处境。

确保微服务高内聚低耦合
在进行微服务拆分之前，应该对平台进行完整的领域划分，建立合适的领域模型，确定好边界上下文，并以此作为微服务拆分的指导。将领域模型的稳定与不断变化的外部需求进行隔离，保证核心领域模型的稳定，避免领域模型之间的强依赖。从而达到实现微服务高内聚低耦合的目的。

总结
本文主要围绕微服务拆分在实践落地层面存在的问题进行了分析，并结合自身的事件经验，可以分别从业务能力维度以及通用能力维度两方面进行拆分，同时提出了微服务拆分的相关原则和建议。希望大家在自己的实际项目中进行微服务拆分落地的时候可以有所参考。