微服务演变及怎么拆分微服务

微服务演变

⼀、微服务演变过程

版本1.0

⼏年前，⼩明和⼩⽪⼀起创业做⽹上超市。⼩明负责程序开发，⼩⽪负责其他事宜。当时互联⽹还不发达，⽹上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单，只需要⼀个⽹站挂在公⽹，⽤户能够在这个⽹站上浏览商品、购买商品；另外还需⼀个管理后台，可以管理商品、⽤户、以及订单数据。

我们整理⼀下功能清单：

⽹站
- ⽤户注册、登录功能
- 商品展示
- 下单
管理后台
- ⽤户管理
- 商品管理
- 订单管理

由于需求简单，⼩明左⼿右⼿⼀个慢动作，⽹站就做好了。管理后台出于安全考虑，不和⽹站做在⼀起，⼩明右⼿左⼿慢动作重播，管理⽹站也做好了。总体架构图如下：

在这里插入图片描述

⼩明挥⼀挥⼿，找了家云服务部署上去，⽹站就上线了。上线后好评如潮，深受各类肥宅喜爱。⼩明⼩⽪美滋滋地开始躺着收钱。

版本2.0

好景不⻓，没过⼏天，各类⽹上超市紧跟着拔地⽽起，对⼩明⼩⽪造成了强烈的冲击。

在竞争的压⼒下，⼩明⼩⽪决定开展⼀些营销⼿段：

开展促销活动。⽐如元旦全场打折，春节买⼆送⼀，情⼈节狗粮优惠券等等。
拓展渠道，新增移动端营销。除了⽹站外，还需要开发移动端APP，微信⼩程序等。
精准营销。利⽤历史数据对⽤户进⾏分析，提供个性化服务。
……

这些活动都需要程序开发的⽀持。⼩明拉了同学⼩红加⼊团队。⼩红负责数据分析以及移动端相关开发。⼩明负责促销活动相关功能的开发。

因为开发任务⽐较紧迫，⼩明⼩红没有好好规划整个系统的架构，随便拍了拍脑袋，决定把促销管理和数据分析放在管理后台⾥，微信和移动端APP另外搭建。通宵了⼏天后，新功能和新应⽤基本完⼯。这时架构图如下：

在这里插入图片描述

这⼀阶段存在很多不合理的地⽅：

⽹站和移动端应⽤有很多相同业务逻辑的重复代码。
数据有时候通过数据库共享，有时候通过接⼝调⽤传输。接⼝调⽤关系杂乱。
单个应⽤为了给其他应⽤提供接⼝，渐渐地越改越⼤，包含了很多本来就不属于它的逻辑。应⽤边界模糊，功能归属混乱。
管理后台在⼀开始的设计中保障级别较低。加⼊数据分析和促销管理相关功能后出现性能瓶颈，影响了其他应⽤。
数据库表结构被多个应⽤依赖，⽆法重构和优化。
所有应⽤都在⼀个数据库上操作，数据库出现性能瓶颈。特别是数据分析跑起来的时候，数据库性能急剧下降。
开发、测试、部署、维护愈发困难。即使只改动⼀个⼩功能，也需要整个应⽤⼀起发布。有时候发布会不⼩⼼带上了⼀些未经测试的代码，或者修改了⼀个功能后，另⼀个意想不到的地⽅出错了。为了减轻发布可能产⽣的问题的影响和线上业务停顿的影响，所有应⽤都要在凌晨三四点执⾏发布。发布后为了验证应⽤正常运⾏，还得盯到第⼆天⽩天的⽤户⾼峰期……
团队出现推诿扯⽪现象。关于⼀些公⽤的功能应该建设在哪个应⽤上的问题常常要争论很久，最后要么⼲脆各做各的，或者随便放个地⽅但是都不维护。

尽管有着诸多问题，但也不能否认这⼀阶段的成果：快速地根据业务变化建设了系统。不过紧迫且繁重的任务容易使⼈陷⼊局部、短浅的思维⽅式，从⽽做出妥协式的决策。在这种架构中，每个⼈都只关注在⾃⼰的⼀亩三分地，缺乏全局的、⻓远的设计。⻓此以往，系统建设将会越来越困难，甚⾄陷⼊不断推翻、重建的循环。

版本3.0

幸好⼩明和⼩红是有追求有理想的好⻘年。意识到问题后，⼩明和⼩红从琐碎的业务需求中腾出了⼀部分精⼒，开始梳理整体架构，针对问题准备着⼿改造。

要做改造，⾸先你需要有⾜够的精⼒和资源。如果你的需求⽅（业务⼈员、项⽬经理、上司等）很强势地⼀⼼追求需求进度，以致于你⽆法挪出额外的精⼒和资源的话，那么你可能⽆法做任何事……

在编程的世界中，最重要的便是抽象能力。微服务改造的过程实际上也是个抽象的过程。⼩明和⼩红整理了⽹上超市的业务逻辑，抽象出公⽤的业务能⼒，做成⼏个公共服务：

⽤户服务
商品服务
促销服务
订单服务
数据分析服务

各个应⽤后台只需从这些服务获取所需的数据，从⽽删去了⼤量冗余的代码，就剩个轻薄的控制层和前端。这⼀阶段的架构如下：

在这里插入图片描述

这个阶段只是将服务分开了，数据库依然是共⽤的，所以⼀些烟囱式系统的缺点仍然存在：

数据库成为性能瓶颈，并且有单点故障的⻛险。
数据管理趋向混乱。即使⼀开始有良好的模块化设计，随着时间推移，总会有⼀个服务直接从数据库取另⼀个服务的数据的现象。
数据库表结构可能被多个服务依赖，牵⼀发⽽动全身，很难调整。

如果⼀直保持共⽤数据库的模式，则整个架构会越来越僵化，失去了微服务架构的意义。因此⼩明和⼩红⼀⿎作⽓，把数据库也拆分了。所有持久化层相互隔离，由各个服务⾃⼰负责。另外，为了提⾼系统的实时性，加⼊了消息队列机制。架构如下：

在这里插入图片描述

完全拆分后各个服务可以采⽤异构的技术。⽐如数据分析服务可以使⽤数据仓库作为持久化层，以便于⾼效地做⼀些统计计算；商品服务和促销服务访问频率⽐较⼤，因此加⼊了缓存机制等。

还有⼀种抽象出公共逻辑的⽅法是把这些公共逻辑做成公共的框架库。这种⽅法可以减少服务调⽤的性能损耗。但是这种⽅法的管理成本⾮常⾼昂，很难保证所有应⽤版本的⼀致性。

数据库拆分也有⼀些问题和挑战：⽐如说跨库级联的需求，通过服务查询数据颗粒度的粗细问题等。但是这些问题可以通过合理的设计来解决。总体来说，数据库拆分是⼀个利⼤于弊的。

微服务架构还有⼀个技术外的好处，它使整个系统的分⼯更加明确，责任更加清晰，每个⼈专⼼负责为其他⼈提供更好的服务。在单体应⽤的时代，公共的业务功能经常没有明确的归属。最后要么各做各的，每个⼈都重新实现了⼀遍；要么是随机⼀个⼈（⼀般是能⼒⽐较强或者⽐较热⼼的⼈）做到他负责的应⽤⾥⾯。在后者的情况下，这个⼈在负责⾃⼰应⽤之外，还要额外负责给别⼈提供这些公共的功能 ——⽽这个功能本来是⽆⼈负责的，仅仅因为他能⼒较强/⽐较热⼼，就莫名地背锅（这种情况还被美其名⽈能者多劳）。结果最后⼤家都不愿意提供公共的功能。⻓此以往，团队⾥的⼈渐渐变得各⾃为政，不再关⼼全局的架构设计。

版本4.0

在这里插入图片描述

⼆、微服务拆分

划分原则

我们拆分微服务的时候需要按照某些原则进⾏拆分.

基于业务逻辑
- 将系统中的业务按照职责范围进⾏识别，职责相同的划分为⼀个单独的服务。
基于稳定性
- 将系统中的业务模块按照稳定性进⾏排序。稳定的、不经常修改的划分⼀块；将不稳定的，经常修改的划分为⼀个独⽴服务。⽐如⽇志服务、监控服务都是相对稳定的服务，可以归到⼀起。
基于可靠性
- 同样，将系统中的业务模块按照可靠性进⾏排序。对可靠性要求⽐较⾼的核⼼模块归在⼀起，对可靠性要求不⾼的⾮核⼼模块归在⼀块。
  
  这种拆分的⾼明可以很好的规避因为⼀颗⽼⿏屎坏了⼀锅粥的单体弊端，同时将来要做⾼可⽤⽅案也能很好的节省机器或带宽的成本。
基于高性能
- 同上，将系统中的业务模块按照对性能的要求进⾏优先级排序。把对性能要求较⾼的模块独⽴成⼀个服务，对性能要求不⾼的放在⼀起。⽐如全⽂搜索，商品查询和分类，秒杀就属于⾼性能的核⼼模块。