微服务演变过程1.0到4.0的演变过程

一、微服务演变过程

版本1.0

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

我们整理一下功能清单：

• 网站
  • 用户注册、登录功能
  • 商品展示
  • 下单
• 管理后台
  • 用户管理
  • 商品管理
  • 订单管理

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

小明挥一挥手，找了家云服务部署上去，网站就上线了。上线后好评如潮，深受各类肥宅喜爱。小明小皮美滋滋地开始躺着收钱。

版本2.0

好景不长，没过几天，各类网上超市紧跟着拔地而起，对小明小皮造成了强烈的冲击。

在竞争的压力下，小明小皮决定开展一些营销手段：

• 开展促销活动。 比如元旦全场打折，春节买二送一，情人节狗粮优惠券等等。
• 拓展渠道，新增移动端营销。 除了网站外，还需要开发移动端APP，微信小程序等。
• 精准营销。 利用历史数据对用户进行分析，提供个性化服务。
• ……

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

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

这一阶段存在很多不合理的地方：

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

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

版本3.0

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

要做改造，首先你需要有足够的精力和资源。如果你的需求方（业务人员、项目经理、上司等）很强势地一心追求需求进度，以致于你无法挪出额外的精力和资源的话，那么你可能无法做任何事……

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

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

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

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

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

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

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

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

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

微服务架构还有一个技术外的好处，它使整个系统的分工更加明确，责任更加清晰，每个人专心负责为其他人提供更好的服务。在单体应用的时代，公共的业务功能经常没有明确的归属。最后要么各做各的，每个人都重新实现了一遍；要么是随机一个人（一般是能力比较强或者比较热心的人）做到他负责的应用里面。在后者的情况下，这个人在负责自己应用之外，还要额外负责给别人提供这些公共的功能——而这个功能本来是无人负责的，仅仅因为他能力较强/比较热心，就莫名地背锅（这种情况还被美其名曰能者多劳）。结果最后大家都不愿意提供公共的功能。长此以往，团队里的人渐渐变得各自为政，不再关心全局的架构设计。

版本4.0

二、微服务拆分

划分原则

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

• 基于业务逻辑

  • 将系统中的业务按照职责范围进行识别，职责相同的划分为一个单独的服务。

• 基于稳定性

  • 将系统中的业务模块按照稳定性进行排序。稳定的、不经常修改的划分一块；将不稳定的，经常修改的划分为一个独立服务。比如日志服务、监控服务都是相对稳定的服务，可以归到一起。

• 基于可靠性

  • 同样，将系统中的业务模块按照可靠性进行排序。对可靠性要求比较高的核心模块归在一起，对可靠性要求不高的非核心模块归在一块。

    这种拆分的高明可以很好的规避因为一颗老鼠屎坏了一锅粥的单体弊端，同时将来要做高可用方案也能很好的节省机器或带宽的成本。

• 基于高性能

  • 同上，将系统中的业务模块按照对性能的要求进行优先级排序。把对性能要求较高的模块独立成一个服务，对性能要求不高的放在一起。比如全文搜索，商品查询和分类，秒杀就属于高性能的核心模块。