程序员就要多研究些架构，少谈些框架
大家好，我是顶级架构师。
三、事件驱动架构
接上篇，我们采用了领域驱动的开发方式，使用了充血模型，享受了他的好处，但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。
事务一致性
事务一致性的问题在Monolithic下面不是大问题，在微服务下面却是很致命，我们回顾一下所谓的ACID原则
Atomicity – 原子性，改变数据状态要么是一起完成，要么一起失败
Consistency – 一致性，数据的状态是完整一致的
Isolation – 隔离线，即使有并发事务，互相之间也不影响
Durability – 持久性， 一旦事务提交，不可撤销
在单体服务和关系型数据库的时候，我们很容易通过数据库的特性去完成ACID。但是一旦你按照DDD拆分聚合根-微服务架构，他们的数据库就已经分离开了，你就要独立面对分布式事务，要在自己的代码里面满足ACID。
对于分布式事务，大家一般会想到以前的JTA标准，2PC两段式提交。我记得当年在Dubbo群里面，基本每周都会有人询问Dubbo啥时候支撑分布式事务。实际上根据分布式系统中CAP原则，当P(分区容忍)发生的时候，强行追求C（一致性），会导致（A）可用性、吞吐量下降，此时我们一般用最终一致性来保证我们系统的AP能力。当然不是说放弃C，而是在一般情况下CAP都能保证，在发生分区的情况下，我们可以通过最终一致性来保证数据一致。
例：
在电商业务的下订单冻结库存场景。需要根据库存情况确定订单是否成交。
假设你已经采用了分布式系统，这里订单模块和库存模块是两个服务，分别拥有自己的存储（关系型数据库），
在一个数据库的时候，一个事务就能搞定两张表的修改，但是微服务中，就没法这么做了。
在DDD理念中，一次事务只能改变一个聚合内部的状态，如果多个聚合之间需要状态一致，那么就要通过最终一致性。订单和库存明显是分属于两个不同的限界上下文的聚合，这里需要实现最终一致性，就需要使用事件驱动的架构。
事件驱动实现最终一致性
事件驱动架构在领域对象之间通过异步的消息来同步状态，有些消息也可以同时发布给多个服务，在消息引起了一个服务的同步后可能会引起另外消息，事件会扩散开。严格意义上的事件驱动是没有同步调用的。
例子：
在订单服务新增订单后，订单的状态是“已开启”，然后发布一个Order Created事件到消息队列上
库存服务在接收到Order Created 事件后，将库存表格中的某sku减掉可销售库存，增加订单占用库存，然后再发送一个Inventory Locked事件给消息队列
订单服务接收到Inventory Locked事件，将订单的状态改为“已确认”
有人问，如果库存不足，锁定不成功怎么办？简单，库存服务发送一个Lock Fail事件， 订单服务接收后，把订单置为“已取消”。
好消息，我们可以不用锁！事件驱动有个很大的优势就是取消了并发，所有请求都是排队进来，这对我们实施充血模型有很大帮助，我们可以不需要自己来管理内存中的锁了。取消锁，队列处理效率很高，事件驱动可以用在高并发场景下，比如抢购。
是的，用户体验有改变，用了这个事件驱动，用户的体验有可能会有改变，比如原来同步架构的时候没有库存，就马上告诉你条件不满足无法下单，不会生成订单；但是改了事件机制，订单是立即生成的，很可能过了一会系统通知你订单被取消掉。就像抢购“小米手机”一样，几十万人在排队，排了很久告诉你没货了，明天再来吧。如果希望用户立即得到结果，可以在前端想办法，在BFF（Backend For Frontend）使用CountDownLatch这样的锁把后端的异步转成前端同步，当然这样BFF消耗比较大。
没办法，产品经理不接受，产品经理说用户的体验必须是没有库存就不会生成订单，这个方案会不断的生成取消的订单，他不能接受，怎么办？那就在订单列表查询的时候，略过这些cancel状态的订单吧，也许需要一个额外的视图来做。我并不是一个理想主义者，解决当前的问题是我首先要考虑的，我们设计微服务的目的是本想是解决业务并发量。而现在面临的却是用户体验的问题，所以架构设计也是需要妥协的:( 但是至少分析完了，我知道我妥协在什么地方，为什么妥协，未来还有可能改变。
多个领域多表Join查询
我个人认为聚合根这样的模式对修改状态是特别合适，但是对搜索数据的确是不方便，比如筛选出一批符合条件的订单这样的需求，本身聚合根对象不能承担批量的查询任务，因为这不是他的职责。那就必须依赖“领域服务（Domain Service）”这种设施。
当一个方法不便放在实体或者值对象上，使用领域服务便是最佳的解决方法，请确保领域服务是无状态的。
我们的查询任务往往很复杂，比如查询商品列表，要求按照上个月的销售额进行排序；要按照商品的退货率排序等等。但是在微服务和DDD之后，我们的存储模型已经被拆离开，上述的查询都是要涉及订单、用户、商品多个领域的数据。如何搞？此时我们要引入一个视图的概念。比如下面的，查询用户名下订单的操作，直接调用两个服务自己在内存中join效率无疑是很低的，再加上一些filter条件、分页，没法做了。于是我们将事件广播出去，由一个单独的视图服务来接收这些事件，并形成一个物化视图（materialized view），这些数据已经join过，处理过，放在一个单独的查询库中，等待查询，这是一个典型的以空间换时间的处理方式。
经过分析，除了简单的根据主键Find或者没有太多关联的List查询，我们大部分的查询任务可以放到单独的查询库中，这个查询库可以是关系数据库的ReadOnly库，也可以是NoSQL的数据库，实际上我们在项目中使用了ElasticSearch作为专门的查询视图，效果很不错。另外，搜索公众号顶级科技后台回复“API接口”，获取一份惊喜礼包。
限界上下文（Bounded Context）和数据耦合
除了多领域join的问题，我们在业务中还会经常碰到一些场景，比如电商中的商品信息是基础信息，属于单独的BC，而其他BC，不管是营销服务、价格服务、购物车服务、订单服务都是需要引用这个商品信息的。但是需要的商品信息只是全部的一小部分而已，营销服务需要商品的id和名称、上下架状态；订单服务需要商品id、名称、目录、价格等等。这比起商品中心定义一个商品（商品id、名称、规格、规格值、详情等等）只是一个很小的子集。这说明不同的限界上下文的同样的术语，但是所指的概念不一样。这样的问题映射到我们的实现中，每次在订单、营销模块中直接查询商品模块，肯定是不合适，因为
商品中心需要适配每个服务需要的数据，提供不同的接口
并发量必然很大
服务之间的耦合严重，一旦宕机、升级影响的范围很大。
特别是最后一条，严重限制了我们获得微服务提供的优势“松耦合、每个服务自己可以频繁升级不影响其他模块”。这就需要我们通过事件驱动方法，适当冗余一些数据到不同的BC去，把这种耦合拆解开。这种耦合有时候是通过Value Object嵌入到实体中的方式，在生成实体的时候就冗余，比如订单在生成的时候就冗余了商品的信息；有时候是通过额外的Value Object列表方式，营销中心冗余一部分相关的商品列表数据，并随时关注监听商品的上下级状态，同步替换掉本限界上下文的商品列表。
下图一个下单场景分析，在电商系统中，我们可以认为会员和商品是所有业务的基础数据，他们的变更应该是通过广播的方式发布到各个领域，每个领域保留自己需要的信息。
保证最终一致性
最终一致性成功依赖很多条件
依赖消息传递的可靠性，可能A系统变更了状态，消息发到B系统的时候丢失了，导致AB的状态不一致
依赖服务的可靠性，如果A系统变更了自己的状态，但是还没来得及发送消息就挂了。也会导致状态不一致
我记得JavaEE规范中的JMS中有针对这两种问题的处理要求，一个是JMS通过各种确认消息（Client Acknowledge等）来保证消息的投递可靠性，另外是JMS的消息投递操作可以加入到数据库的事务中-即没有发送消息，会引起数据库的回滚（没有查资料，不是很准确的描述，请专家指正）。不过现在符合JMS规范的MQ没几个，特别是保一致性需要降低性能，现在标榜高吞吐量的MQ都把问题抛给了我们自己的应用解决。所以这里介绍几个常见的方法，来提升最终一致性的效果。
使用本地事务
还是以上面的订单扣取信用的例子
订单服务开启本地事务，首先新增订单；
然后将Order Created事件插入一张专门Event表，事务提交；
有一个单独的定时任务线程，定期扫描Event表，扫出来需要发送的就丢到MQ，同时把Event设置为“已发送”。
方案的优势是使用了本地数据库的事务，如果Event没有插入成功，那么订单也不会被创建；线程扫描后把event置为已发送，也确保了消息不会被漏发（我们的目标是宁可重发，也不要漏发，因为Event处理会被设计为幂等）。
缺点是需要单独处理Event发布在业务逻辑中，繁琐容易忘记；Event发送有些滞后；定时扫描性能消耗大，而且会产生数据库高水位隐患；
我们稍作改进，使用数据库特有的MySQL Binlog跟踪（阿里的Canal）或者Oracle的GoldenGate技术可以获得数据库的Event表的变更通知，这样就可以避免通过定时任务来扫描了
不过用了这些数据库日志的工具，会和具体的数据库实现（甚至是特定的版本）绑定，决策的时候请慎重。
使用Event Sourcing 事件溯源
事件溯源对我们来说是一个特别的思路，他并不持久化Entity对象，而是只把初始状态和每次变更的Event记录下来，并在内存中根据Event还原Entity对象的最新状态，具体实现很类似数据库的Redolog的实现，只是他把这种机制放到了应用层来。
虽然事件溯源有很多宣称的优势，引入这种技术要特别小心，首先他不一定适合大部分的业务场景，一旦变更很多的情况下，效率的确是个大问题；另外一些查询的问题也是困扰。
我们仅仅在个别的业务上探索性的使用Event Souring和AxonFramework，由于实现起来比较复杂，具体的情况还需要等到实践一段时间后再来总结，也许需要额外的一篇文章来详细描述
以上是对事件驱动在微服务架构中一些我的理解，文章部分借鉴了Chris Richardson的Blog，https://www.nginx.com/blog/event-driven-data-management-microservices/ 在此我向他表示致谢 。
四、 架构师是技术的使用者
架构师是技术的使用者而不是信徒
我承认我是标题党， 为什么要写这篇充满争议的文章？目前架构师这个职位特别火热，程序员的目标都是成为一个令人尊敬的架构师。但是我们真的理解架构师应该做些什么？很多人把架构师和框架师等同起来，认为研究框架多的才是架构师
下面说的情况请勿对号入座。
盲目的追新：
技术人员的喜好往往是什么技术流行就追什么技术。现在的技术发展快，前后端不断涌现各种框架，我们恨不得把这些框架都用在自己的项目里才行，要不然怎么好意思和别人打招呼啊。
我亲身经历，有个技术人员一定要把原来单元测试框架的xml初始数据改为json，他的原话是”json看的更舒服”，但是改完后，我们的单元测试反而难落地了，原因是原来的单元测试框架有个工具是可以将表中的数据自动生成xml的，而改成json后，我们必须手写json数据了。他的喜好不包括给大家更好用的工具。
按技术站队，以结果反推：
很多人把手段当成了目的，成为了框架的信徒。用了Java开发，你的设计就一定是面向对象的？用了Spring boot就是微服务了吗？这些荒唐的事情却在技术圈不断发生，技术人员甚至会按照语言、框架形成不同的圈子，各种技术圈互相鄙视，互相踩，真相此时无法越辩越明，反而把技术方向带歪了。
技术要和实际场景结合
架构师也要深入了解掌握技术，但是更多的是了解技术的优劣和使用场景，而不是简单的生搬硬套。以现在流行的微服务架构来说，Netflix使用RESTful接口作为通讯，我们是不是要把公司的用了n年的基于TCP的RPC换成RESTful接口，因为根据Netflix的实践，RESTful可以更好的解耦、更强的伸缩性等优点，还能支持多种语言开发，互通性好。但是我们需要对RESTful彻底的理解清楚：
RESTful接口不简单是是http+json，Richardson成熟度模型中哪个层级更合适我们的内网API通讯，HATEOAS是否需要？
RESTful的核心是资源，如何在微服务中抽象资源概念，如何将基于过程的RPC调用平滑的迁移到RESTful上？
多语言开发是快，但是后续维护如何找到稳定的Go、Scala、xxx语言程序员来源？
以上的问题应该是架构师在考虑引入新技术的时候的重点，其中对技术优劣和架构思路是核心。
欢迎大家进行观点的探讨和碰撞，各抒己见。如果你有疑问，也可以找我沟通和交流。扩展：接私活儿
最后给读者整理了一份BAT大厂面试真题，需要的可扫码回复“面试题”即可获取。
「顶级架构师」建立了读者架构师交流群，大家可以添加小编微信进行加群。欢迎有想法、乐于分享的朋友们一起交流学习。
扫描添加好友邀你进架构师群，加我时注明【姓名+公司+职位】
版权申明：内容来源网络，版权归原作者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。
猜你还想看
牛逼！接私活必备的 N 个系统项目！赶快收藏吧（附源码合集第 3 期）！
Spring Boot + Redis 实现各种操作，写得太好了吧！