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

这个系列咱们大概写了八篇文章，将微服务的最重要的内容过了一遍。固然其中有些内容尚未涉及到，好比Docker（不是微服务架构风格中必须的）等，关于Docker咱们本身能够在网上找找其余文章。

这篇文章就来回顾下微服务架构风格是如何落地的，若是你对如下回顾的内容都很清楚并已经有一些实践的经验，那么恭喜你，你已经进入了微服务的大门。

1、什么是微服务

由于客户对现代化的产品和系统的须要，对软件开发自己提出了更高的要求，这些要求包括：
1.服务独立性，互不影响：包括各小组能独立开发；服务能独立部署与运行；不一样上下文中能够有不一样的技术选型。
2.高性能大并发：接口可以快速响应请求；队列处理业务可以支持大并发；查询的性能要好。
3.事件溯源与最终一致性：可以跟踪对象历史变化状态；可以回溯对象到任意的状态。
4.服务高可用性：数据尽可能可以访问；服务尽可能可以调用；服务最好能集中管理。

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

1.经过构建EDA（事件驱动的架构）并结合消息总线，解决服务独立性的问题。
2.经过构建CQRS（命令查询职责分离的架构）并结合消息总线，解决大并发高性能的问题。
3.经过构建Event存储与还原的机制，实现事件溯源，解决最终一致性的问题，也解决业务上有对象历史状态获取的需求。
4.经过数据库产品自己高可用行，弹性访问实现数据访问高可用；经过实现WebApi负载平衡、重试与断路器、Api网关与服务中心等方式，实现WebApi的高可用。

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

2、实现微服务

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就根据产品的特色能够选择性的使用，必定要让你的架构是可演进的，而不是照搬。

3、总体架构图

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

QQ讨论群：309287205 DDD实战进阶视频请关注微信公众号：msshcj