微服务演变
⼀、微服务演变过程
版本1.0
⼏年前，⼩明和⼩⽪⼀起创业做⽹上超市。⼩明负责程序开发，⼩⽪负责其他事宜。当时互联⽹还不发 达，⽹上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单，只需要⼀个⽹站挂在 公⽹，⽤户能够在这个⽹站上浏览商品、购买商品；另外还需⼀个管理后台，可以管理商品、⽤户、以 及订单数据。
我们整理⼀下功能清单：
- ⽹站
- ⽤户注册、登录功能
- 商品展示
- 下单
- 管理后台
- ⽤户管理
- 商品管理
- 订单管理
由于需求简单，⼩明左⼿右⼿⼀个慢动作，⽹站就做好了。管理后台出于安全考虑，不和⽹站做在⼀ 起，⼩明右⼿左⼿慢动作重播，管理⽹站也做好了。总体架构图如下：
⼩明挥⼀挥⼿，找了家云服务部署上去，⽹站就上线了。上线后好评如潮，深受各类肥宅喜爱。⼩明⼩ ⽪美滋滋地开始躺着收钱。
版本2.0
好景不⻓，没过⼏天，各类⽹上超市紧跟着拔地⽽起，对⼩明⼩⽪造成了强烈的冲击。
在竞争的压⼒下，⼩明⼩⽪决定开展⼀些营销⼿段：
-
开展促销活动。 ⽐如元旦全场打折，春节买⼆送⼀，情⼈节狗粮优惠券等等。
-
拓展渠道，新增移动端营销。 除了⽹站外，还需要开发移动端APP，微信⼩程序等。
-
精准营销。 利⽤历史数据对⽤户进⾏分析，提供个性化服务。
-
……
这些活动都需要程序开发的⽀持。⼩明拉了同学⼩红加⼊团队。⼩红负责数据分析以及移动端相关开 发。⼩明负责促销活动相关功能的开发。
因为开发任务⽐较紧迫，⼩明⼩红没有好好规划整个系统的架构，随便拍了拍脑袋，决定把促销管理和 数据分析放在管理后台⾥，微信和移动端APP另外搭建。通宵了⼏天后，新功能和新应⽤基本完⼯。这 时架构图如下：
这⼀阶段存在很多不合理的地⽅：
-
⽹站和移动端应⽤有很多相同业务逻辑的重复代码。
-
数据有时候通过数据库共享，有时候通过接⼝调⽤传输。 接⼝调⽤关系杂乱。
-
单个应⽤为了给其他应⽤提供接⼝，渐渐地越改越⼤，包含了很多本来就不属于它的逻辑。 应⽤边 界模糊，功能归属混乱。
-
管理后台在⼀开始的设计中保障级别较低。 加⼊数据分析和促销管理相关功能后出现性能瓶颈，影 响了其他应⽤。
-
数据库表结构被多个应⽤依赖，⽆法重构和优化。
-
所有应⽤都在⼀个数据库上操作，数据库出现性能瓶颈。 特别是数据分析跑起来的时候，数据库性 能急剧下降。
-
开发、测试、部署、维护愈发困难。 即使只改动⼀个⼩功能，也需要整个应⽤⼀起发布。 有时候 发布会不⼩⼼带上了⼀些未经测试的代码，或者修改了⼀个功能后，另⼀个意想不到的地⽅出错 了。 为了减轻发布可能产⽣的问题的影响和线上业务停顿的影响，所有应⽤都要在凌晨三四点执⾏ 发布。 发布后为了验证应⽤正常运⾏，还得盯到第⼆天⽩天的⽤户⾼峰期……
-
团队出现推诿扯⽪现象。 关于⼀些公⽤的功能应该建设在哪个应⽤上的问题常常要争论很久，最后 要么⼲脆各做各的，或者随便放个地⽅但是都不维护。
尽管有着诸多问题，但也不能否认这⼀阶段的成果：快速地根据业务变化建设了系统。不过紧迫且繁重 的任务容易使⼈陷⼊局部、短浅的思维⽅式，从⽽做出妥协式的决策。在这种架构中，每个⼈都只关注 在⾃⼰的⼀亩三分地，缺乏全局的、⻓远的设计。⻓此以往，系统建设将会越来越困难，甚⾄陷⼊不断 推翻、重建的循环。
版本3.0
幸好⼩明和⼩红是有追求有理想的好⻘年。意识到问题后，⼩明和⼩红从琐碎的业务需求中腾出了⼀部 分精⼒，开始梳理整体架构，针对问题准备着⼿改造。
要做改造，⾸先你需要有⾜够的精⼒和资源。如果你的需求⽅（业务⼈员、项⽬经理、上司等）很 强势地⼀⼼追求需求进度，以致于你⽆法挪出额外的精⼒和资源的话，那么你可能⽆法做任何 事……
在编程的世界中，最重要的便是抽象能力。微服务改造的过程实际上也是个抽象的过程。⼩明和⼩红整 理了⽹上超市的业务逻辑，抽象出公⽤的业务能⼒，做成⼏个公共服务：
-
⽤户服务
-
商品服务
-
促销服务
-
订单服务
-
数据分析服务
各个应⽤后台只需从这些服务获取所需的数据，从⽽删去了⼤量冗余的代码，就剩个轻薄的控制层和前 端。这⼀阶段的架构如下：
这个阶段只是将服务分开了，数据库依然是共⽤的，所以⼀些烟囱式系统的缺点仍然存在：
- 数据库成为性能瓶颈，并且有单点故障的⻛险。
- 数据管理趋向混乱。 即使⼀开始有良好的模块化设计，随着时间推移，总会有⼀个服务直接从数据 库取另⼀个服务的数据的现象。
- 数据库表结构可能被多个服务依赖，牵⼀发⽽动全身，很难调整。
如果⼀直保持共⽤数据库的模式，则整个架构会越来越僵化，失去了微服务架构的意义。因此⼩明和⼩ 红⼀⿎作⽓，把数据库也拆分了。所有持久化层相互隔离，由各个服务⾃⼰负责。另外，为了提⾼系统 的实时性，加⼊了消息队列机制。架构如下：
完全拆分后各个服务可以采⽤异构的技术。⽐如数据分析服务可以使⽤数据仓库作为持久化层，以便于 ⾼效地做⼀些统计计算；商品服务和促销服务访问频率⽐较⼤，因此加⼊了缓存机制等。
还有⼀种抽象出公共逻辑的⽅法是把这些公共逻辑做成公共的框架库。这种⽅法可以减少服务调⽤ 的性能损耗。但是这种⽅法的管理成本⾮常⾼昂，很难保证所有应⽤版本的⼀致性。
数据库拆分也有⼀些问题和挑战：⽐如说跨库级联的需求，通过服务查询数据颗粒度的粗细问题 等。但是这些问题可以通过合理的设计来解决。总体来说，数据库拆分是⼀个利⼤于弊的。
微服务架构还有⼀个技术外的好处，它使整个系统的分⼯更加明确，责任更加清晰，每个⼈专⼼负责为 其他⼈提供更好的服务。在单体应⽤的时代，公共的业务功能经常没有明确的归属。最后要么各做各 的，每个⼈都重新实现了⼀遍；要么是随机⼀个⼈（⼀般是能⼒⽐较强或者⽐较热⼼的⼈）做到他负责 的应⽤⾥⾯。在后者的情况下，这个⼈在负责⾃⼰应⽤之外，还要额外负责给别⼈提供这些公共的功能 ——⽽这个功能本来是⽆⼈负责的，仅仅因为他能⼒较强/⽐较热⼼，就莫名地背锅（这种情况还被美其 名⽈能者多劳）。结果最后⼤家都不愿意提供公共的功能。⻓此以往，团队⾥的⼈渐渐变得各⾃为政， 不再关⼼全局的架构设计。
版本4.0
⼆、微服务拆分
划分原则
我们拆分微服务的时候需要按照某些原则进⾏拆分.
-
基于业务逻辑
- 将系统中的业务按照职责范围进⾏识别，职责相同的划分为⼀个单独的服务。
-
基于稳定性
- 将系统中的业务模块按照稳定性进⾏排序。稳定的、不经常修改的划分⼀块；将不稳定的，经 常修改的划分为⼀个独⽴服务。⽐如⽇志服务、监控服务都是相对稳定的服务，可以归到⼀ 起。
-
基于可靠性
-
同样，将系统中的业务模块按照可靠性进⾏排序。对可靠性要求⽐较⾼的核⼼模块归在⼀起， 对可靠性要求不⾼的⾮核⼼模块归在⼀块。
这种拆分的⾼明可以很好的规避因为⼀颗⽼⿏屎坏了⼀锅粥的单体弊端，同时将来要做⾼可⽤ ⽅案也能很好的节省机器或带宽的成本。
-
-
基于高性能
- 同上，将系统中的业务模块按照对性能的要求进⾏优先级排序。把对性能要求较⾼的模块独⽴ 成⼀个服务，对性能要求不⾼的放在⼀起。⽐如全⽂搜索，商品查询和分类，秒杀就属于⾼性 能的核⼼模块。
基于上诉的拆分原则，我们可以针对骡窝窝项⽬进⾏微服务的拆分:
- 游记服务
- ⽬的地管理
- 旅游攻略
- 旅游⽇记
- …
- 评论服务
- 旅游功能评论
- 旅游⽇记评论
- 景点评论
- 旅⾏社评论
- …
- ⽤户服务
- ⽤户个⼈中⼼
- ⽤户积分相关
- ⿊名单/⽩名单
- 粉丝关注
- …
- 消息服务
- 短信通知
- 邮件通知
- 站内信
- …
- 搜索服务
- 攻略搜索
- 游记搜搜
- ⽤户搜索
- 景点搜索
- …
人员配置
假如我们按照业务来划分，根据粒度⼤⼩，可能存在以下两种：
-
第⼀种分为商品、交易、⽤户3个服务；
-
第⼆种分为商品、订单、⽀付、物流、买家、卖家6个服务。
3 VS 6，这该怎么办？
如果你的团队只有9个⼈，那么分成3个是合理的，如果有18个⼈，那么6个服务是合理的。这⾥引 ⼊团队成员进⾏协助拆分。
在拆分遇到争议的时候，⼀般情况下我们增加⼀项拆分条件，虽然不是充要条件，但⾄少我们的答 案会更加接近真理。
除了业务可能存在争议，其他的划分也会有争议，⽐如⼀个独⽴的服务到底需要多少⼈员的配置？
为什么说是三个⼈分配⼀个服务（当然，成员主要是后端⼈员）？
假设是1个⼈，请个假、⽣个病都不⾏。⼀个⼈会遇到单点的问题，所以不合理。
假设是2个⼈，终于有备份了，但是抽离⼀个后，剩下1个压⼒还是很⼤，不合理。
假设是3个⼈，抽离⼀个还有2个在。⽽且数字3是个稳定⽽神奇数字，⽤得好事半功倍。特别是遇 到技术讨论，3个⼈相对周全，如果是2个可能会各持⼰⻅，带有⾃我的偏⻅和盲区。
那么这个3是不是就是稳定的数量呢？
假设你做的是边开⻜机边换引擎的重写⼯作，那么前期3个⼈都可能捉襟⻅肘。但是到了服务后期， 你可能1个就够了。