微服务实战：落地微服务架构到直销系统(回顾总结)

一、什么是微服务

因为客户对现代化的产品和系统的需要，对软件开发本身提出了更高的要求，这些要求包括：

1.服务独立性，互不影响：包括各小组能独立开发；服务能独立部署与运行；不同上下文中可以有不同的技术选型。

2.高性能大并发：接口能够快速响应请求；队列处理业务能够支持大并发；查询的性能要好。

3.事件溯源与最终一致性：能够跟踪对象历史变化状态；能够回溯对象到任意的状态。

4.服务高可用性：数据尽量能够访问；服务尽量能够调用；服务最好能集中管理。

为了解决上述的开发过程、部署过程以及运行过程中的问题，需要一种新的架构风格来指导产品的开发、部署与运行，这种架构风格就是微服务。微服务架构风格提出以下几个要求来解决上述问题，并应对用户与市场对我们的产品与软件提出的更高要求。

1.通过构建EDA（事件驱动的架构）并结合消息总线，解决服务独立性的问题。

2.通过构建CQRS（命令查询职责分离的架构）并结合消息总线，解决大并发高性能的问题。

3.通过构建Event存储与还原的机制，实现事件溯源，解决最终一致性的问题，也解决业务上有对象历史状态获取的需求。

4.通过数据库产品本身高可用行，弹性访问实现数据访问高可用；通过实现WebApi负载平衡、重试与断路器、Api网关与服务中心等方式，实现WebApi的高可用。

所以，微服务是一种架构风格，它旨在通过将一个大系统分解成多个小系统（DDD中的界限上下文），并通过一系列的架构建议，解决服务独立性、性能、事件溯源与最终一致、高可用性的需求，最终使多个界限上下文能够相互协作，组合成一个为用户提供高质量的服务的大系统。

二、实现微服务

1.实现微服务的最关键内容就是实现一个事件总线，事件总线既用于微服务之间的通信松耦合、也对大并发高性能的要求提供底层支持。

 

实现的事件总线的大概步骤是：

a.定义事件消息接口。

b.定义事件消息处理器接口。

c.定义事件消息与事件消息处理器接口的关联关系。

d.定义消息发布、消息订阅、消息总线相关的接口。

e.实现事件消息基类与事件消息总线基类。

f.实现事件消息与处理器的关联。

2.实现微服务的第二个关键内容就是要支持CQRS架构，这样在对抗大并发时会有很好的支持。

 

实现CQRS架构大并发的大概方法与原理是：

a.命令与查询走不同的WebApi服务，将更改系统状态的行为与查询的行为做很好的隔离，并可以部署微服务到不同的服务器上，当然还可以通过NLB做进一步的扩展。

b.命令端的WebApi并不直接处理调用用例完成，而是接收到用户命令时，将命令消息发布到消息总线，然后立刻返回一个操作信息给用户，这样用户体验很好，不需要等待业务逻辑完成与持久化完成。

c.命令处理器WebApi从消息队列侦听到消息，然后进行处理，处理的主要内容是完成领域逻辑调用，直接添加事件数据到事件存储中。这里需要注意的是，并不是持久化到业务数据库中。首先完成领域逻辑调用，可以得到用例最终正确的领域对象，然后存储事件时，存储这次领域对象的状态，并且是直接添加。这样做的好处有：一是加快持久化，二是能够保存领域对象每次变化的信息，未来可以用于历史追踪、事件溯源与最终一致性。

事件存储是个重要的基础，它主要的实现步骤是：构建事件存储表、重构事件类支持事件存储、实现存储的事件对象、实现事件对象的存储功能。

d.命令处理器将领域对象发送到消息总线中，事件处理器会侦听队列，并最终将消息信息涉及到的领域对象持久化到业务数据库中。

e.在查询WebApi中，可以直接查询业务库，如果业务库并不适合多表连接查询时，可以再单独做个拉平的为查询提供服务的查询库。查询库的内容可以通过业务库更新成功后，发布消息到另一个队列中，然后通过处理器来处理这些数据到查询库中。

另外需要特别注意的是，在实际的高性能系统中，查询可能并不会走业务库（写库），而是单独做一个查询库（读库）并实现相关的查询WebApi，查询库的结构是按照前端查询方面的原型来做设计。这样就很好的做到了读写分离，关于读写分离的最佳实践，大家可以参考微信公众号文章。

3.实现微服务的第三个关键内容是服务的高可用性。

a.保证微服务负载可用：这里的负载要实现数据库层面、微服务WebApi层面、重试策略、断路器模式。

b.保证微服务地址可用：主要通过API网关与服务中心实现。

至此，我们就基本上实现了微服务架构风格的系统。一定要注意的是，当我们需要应对市场对系统提到的要求，而这种要求只有微服务架构风格才能很好支持时，才使用；不要盲目的使用，也不要全部使用，比如CQRS就根据产品的特点可以选择性的使用，一定要让你的架构是可演进的，而不是照搬。

三、整体架构图

根据整个系列的文章，实际上我们就实现了这两个整体架构图：