????欢迎点赞 ：???? 收藏 ⭐留言 ???? 如有错误敬请指正，赐人玫瑰，手留余香！
????本文作者：由webmote 原创，首发于 【掘金】
????作者格言：生活在于折腾，当你不折腾生活时，生活就开始折腾你，让我们一起加油！????????????
???? 序言
“滚滚长江东逝水，浪花淘尽英雄。”
技术之路上，繁星点点，今天且来看看“微服务 ”，如何称雄。
“微服务” 这个词好像已经出来十年了吧，我有幸从好早之前就一直从事相关的开发实践。所以一直想写有关微服务拆分的题材，但都觉得自己理解不到位，难以下笔。
因为没有系统的理论知识，很难写出什么新花样。????????????
直到最近参加了ThoughtWork的系列直播课，我觉得是时候系统的整理下学习心得，也算给最近的听课以交代。
里面夹杂了自己的实践感悟，写的不一定能面面俱到，也不可能准确无误，欢迎大家纠正！共同????交流探讨。
???? 01.微服务是啥？
微服务(Microservice)概念据说是在2012年出现，其一出现就对互联网行业产生了巨大影响，因为其理念刚好符合“分而治之”的思想，在日益巨大化的互联网行业内，不免逐步产生了无法把控的思绪混乱，而“微”刚好能解决这个痛点。
先不上定义，仅从字面意思，我们就能看出，微服务即是小服务，巨大的服务怎么看也和“微”格格不入。
掘金牙医曾经写过一篇《我在掘金这3年 - 如何给飞行中的飞机换引擎》，在其中有段阐述，我觉得理解的很有地气。
我们将 Wordpress(一款php语言编写的个人博客系统) 无限拆分, 拆分到每个 function 都构成一个服务 (因为再细分已经毫义, 把一个大小, 功能适当的 function 再拆开只会降低性能徒增复杂度). 那么以 function 为服务最小单位的 repo 组成的业务就是服务中的最小模式了.
为了讨论的简便, 我们直接把最小服务模式叫 Picoservice. 最大模式叫 Polyservice. Polyservice 的话我们刚才说的 Wordpress 就是个很好的例子, 现实中 Polyservice 有很多, 传统业务可能都是这样组织代码的, 相信大家也都见到过. 但每个 function 都拆分成服务的业务可不多见, 我粗略统计了下 Wordpress 大概有一万个 function. 可以想象将 Wordpress 拆分成 Picoservice 最后组织成业务是多么可怕的事情. 现实中只有 FAAS 平台上运行的业务可能是以单个 function 的形式组成并运行的.
依据服务大小的定义, 我们可以把现有的服务类型按照大小进行排序:
Picoservice <= FAAS(or ServerLess) < Microservice < Monoservice <= Polyservice
注意: 服务大小跟服务部署规模没有关系, 无论是 Picoservice 还是 Polyservice, 只要设计得当都可以多机部署以提升性能.
看过接地气的描述外，回头我们再看看微服务真正的定义是啥？
“微服务”是是一种架构模式，它提倡将单一的应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级的通信机制互相沟通。每个服务都围绕具体业务进行构建，并且能够被独立的部署到生产环境。
简而言之，微服务是一种将单个应用以许多微小服务所组成的服务套件的形式来构建软件的方法，每个微服务拥有自己的轻量级数据处理模块以及通信机制（通常是 HTTP API 的形式）。微服务围绕业务能力和各自独立的自动化部署机制构建而来。由于微服务需要极少的集中管理，因此各个服务可以使用不同的编程语言以及存储技术。
当年写三国的罗贯中虽然没有做过码农，编写过前后端代码，经历过内卷的996、007，承担过系统架构师，但其凭借自己敏锐的洞察力，在当时已经提出了IT界技术发展更迭的规律: 话说天下大势，分久必合，合久必分。周末七国分争，并入于秦。及秦灭之后，楚、汉分争，又并入于汉。汉朝自高祖斩白蛇而起义，一统天下，后来光武中兴，传至献帝，遂分为三国。
你品，你细品！中文文化的博大精深，底蕴深厚令人折服！
“分而治之”是微服务的精髓！理解了这个精髓，就可以如庖丁解牛般设计你的系统架构。当然以后肯定有某架构，一统江山，又是大势所趋，这是后话，按下不表。
???? 02.微服务的诞生轨迹？
既然明白了“分久必合，合久必分”的理论知识，那我们来看看微服务的诞生轨迹。
沿着分分分的路，越走越远。
由于把许多独立的业务拆成不同的微服务，因此带来的微服务构建的复杂度，一般表现为下列几点：
微服务的注册和发现
微服务的部署和弹性伸缩
微服务间的通讯
微服务间通讯的效率
微服务间的事务性（ACID）
微服务的对外网关、限流熔断
微服务的全局配置
微服务的认证授权（OAuth2）
微服务间的异步通讯、消息
微服务的日志
微服务的监控
以上难题也是大型分布式应用的难题。
因此在我们的应用规模没有上去之前，考虑到时间成本和其他复杂度要素，仍然可以按照单体 > SOA > 微服务的进阶步骤一步步实施。
???? 03.微服务的打开方式？
从A点到B点，直线距离永远是最短的，然而往往这条路也是走的最艰难的！所以这世上多了很多的盘山公路！
不管是旧系统的改造，还是新系统的构建，直接冲向微服务是有很大的风险的。
因此一般的实践建议是：
单体或粗粒度服务优先，避免过度设计；
业务演进过程中加深对业务边界的理解；
避免前期因服务划分不合理带来的大量重构工作；
当然如果在团队中坏味道已经肆意弥漫了，那就是时候先动手了。是的，是我先动的手。
有几种重要的拆分方式：
???? 03.1 事件风暴法
该方法来自传统的DDD领域建模界，DDD方式在互联网应用中被使用的很少，原因有很多了，这里指出的重要的几点供你参考：
争端太大，大家对DDD的理解各不相同，并没有太好的标准说服对方；
慢，毕竟要理清楚各个业务边界不是那么容易的，而互联网应用一般是说好了就干；
事件、命令、聚合根、实体等概念诸多，理解不易。
虽然有诸多缺点，但瑕不掩瑜，在微服务划分上，DDD异军突起，起到了关键的理论指导意义。
事件风暴法是集合业务人员、领域专家、技术人员、架构和测试人员等一起寻找事件、命令、领域模型，直到划分界限上下文和识别出问题域。
以下步骤略显枯燥，谨慎阅读。
03.1.1 寻找领域事件
领域事件：捕获建模领域中所发生的事情
识别：领域专家所关心的事情，业务上真实发生，有事件顺序
甄别：领域事件必须是对业务有价值的，必须将导致进一步业务操作的
一个例子：在商品订单业务中。
领域事件：
商品已创建、商品已编辑
商品已发布
订单已创建、订单已取消
库存已扣减
出库单已生成
出库单已配货
出库单已发货
订单已发货
订单已签收
订单已确认收货
03.1.2 寻找命令
命令：产生事件的领域行为或领域活动
识别：用户的动作、外部系统触发、定时任务
接上个例子，有可能的命令：
添加商品、编辑商品
发布商品
添加订单、取消订单
定时生成出库单
配货
发货
订单签收
订单确认
03.1.3 寻找领域模型
领域模型：是对业务领域内的概念类或现实世界中对象的可视化表示
识别：是否可以被独立访问（可以：就是聚合，不能：属于它依赖的聚合）
做法：留下聚合即时贴，命令在左，事件在右。
03.1.4 划分限界上下文
限界上下文：某场景或环境下的业务边界
识别：定义业务场景，然后找寻业务边界
方法：识别出相邻事件的关系，确立上下游角色。一般来说，发布事件的为下游，订阅事件的为上游。
例如下面：
03.1.5 识别问题域
问题域：需要讨论的问题范围
识别：站在业务专家的角度看待问题，只能通过与最理解该领域的人一同协作才能完成。
???? 03.2 8X Flow业务建模法
8X Flow是ThoughtWorks 中国区CTO徐昊研究并设计的方法论。
DDD解释中最容易混淆的是领域的概念本身，通俗的认为领域是问题的集合，问题又是业务的抽象。
那么，领域和业务到底有啥区别呢？
徐昊观点：Domain + operation（运维） = business， 领域比较抽象，再更进一步抽象可以变成领域专家系统， 专家可以支撑业务。
8x Flow的分析方法步骤：
主要思想是寻找业务合约（订单支付凭据、订单发货凭据、订单收货凭据等等），基于这些凭据，构造支付流程、发货流程、收货流程等。甚至于演化为限界上下文。
???? 04. 拆分微服务的原则
微服务拆分应遵循的原则，描述如下：
低耦合，单一职责
微服务的设计和面向对象的设计原则类似，也需要符合低耦合、单一职责的设计原则。单向依赖
杜绝循环和双向依赖。采用消息解耦上下游服务。定义上下游
下面的图说的非常清晰，上下游服务应遵循下述调用方式。
数据操作独立
数据隔离，让服务操作自身数据。构造BFF
为前端应用构造BFF服务，整合微服务间的融合。
???? 05. 结语
微服务按照DDD拆分太烧脑了，也许正如徐昊所说，很多公司的应用应该是业务优先，而不是领域优先，也即很多的业务逻辑，很少的领域逻辑，那么我们拆分这些业务时，完全按照DDD必将陷入迷茫之中。
适合自己的才是最好的，我们掌握这么多方法是为了灵活解决实际的问题，而不是被困在这些武器内不可自拔，甚至发出没有DDD就不是好的微服务的谬论。
后续还会有很长的真实的实践，实践之后再回来总结下。
例行小结，理性看待！
结的是啥啊，结的是我想你点赞而不可得的寂寞。????????????
????都看到这了，还在乎点个赞吗？
????都点赞了，还在乎一个收藏吗？
????都收藏了，还在乎一个评论吗？
