其他分享
首页 > 其他分享> > 微服务实战(九):落地微服务架构到直销系统(回顾总结)

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

作者:互联网

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

这个系列我们大概写了八篇文章,将微服务的最重要的内容过了一遍。当然其中有些内容还没有涉及到,比如Docker(不是微服务架构风格中必须的)等,关于Docker我们自己可以在网上找找其他文章。

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

 

一、什么是微服务

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

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就根据产品的特点可以选择性的使用,一定要让你的架构是可演进的,而不是照搬。

 

三、整体架构图

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

 

 

QQ讨论群:309287205 

微服务实战视频请关注微信公众号:

标签:架构,实现,查询,回顾总结,事件,服务,直销,消息
来源: https://www.cnblogs.com/lonelyxmas/p/10903202.html