小规模团队微服务架构实践

序

网络上介绍微服务的文章很多，但是针对小规模团队如何实践微服务架构的文章很少，而照搬大公司的做法并不完全适合，很容易失败。
笔者在这个过程中也走过很多弯路，所以写了这篇文章，一方面做一个整理总结，更多的是希望能抛砖引玉，帮助他人，也被他人帮助。
本文通过公司一个近期的实际产品，从0到1介绍设计和实现的过程。
限于个人的能力和经验，难免有不足之处，所以诚惶诚恐，希望得到大家的指正。

个人对于微服务的理解

思想的高度决定行动的水平，我理解的微服务应该是这样的。

1. 微服务是一种思想，然后才是技术。
2. 微服务的核心思想是化繁为简。
3. 微服务是一个理想，对于微服务不能完美实现的系统，可以混合传统方式实现。
4. 微服务是需要迭代的，很难一步到位。

微服务思维

整个团队包括产品、设计、研发、测试、运维都应该具备微服务思维。
整个团队包括产品、设计、研发、测试、运维都应该具备微服务思维。
整个团队包括产品、设计、研发、测试、运维都应该具备微服务思维。
重要的事情说三遍。
既然是一种思想，首先的，整个团队要统一认识。

认识误区

对于微服务，经常有一个认识上的误区，产品和设计只关注完整的业务流程和输出高保真，微服务化的工作交给技术去做。这是很多团队失败的重要原因，我们也犯过同样的错误。其导致的问题包括：

1. 产品和研发对于工作量的估计偏差很大。
   成功微服务架构的特点是，前期设计开发工作量大，后期维护和升级的工作量小，传统单体应用刚好相反。
   在前期，微服务设计考虑的东西比传统单体应用多很多，单体应用关注接口、流程、模块化、数据结构，而微服务首先要考虑服务划分，权衡划分粒度，服务之间的层级、调用、解耦等关系及部署时的组合、调度等等问题，同时每个被划分好的微服务也是一个单体应用，除了需要考虑单体应用关注的接口、流程、模块化、数据结构，还要考虑微服务之间的数据同步问题等等。
   产品迭代的第一个版本，微服务可能已经有超过10个，例如：基础服务统一配置 config, 路由Gateway，权限Acl，通用用户User，单点登陆SSO, 通行证Passport, 以及微信相关服务 Wechat，Weapp，passport-weapp， passport-wechat，还有一些业务逻辑系统。
   这时候开发人员面临的决定就非常艰难，如果先划分，第一个版本开发周期估计至少要一个月以上，如果先做在一起，后期再划分，势必造成很多额外重构工作，费时费力。而产品给的时间只有一个周，要包含设计、开发、测试、上线，因为产品按照传统单体应用估算工作量，而且还要求快速迭代，他们只关心结果。所以，常常项目一启动，就已经失败了。
2. 产品需求的修改对于技术的影响非常大。
   启动时基础不好，微服务设计的必然不会很好，大多做成四不像，把一个单体应用做成了几个单体应用，增加了整体的复杂度，产品需求的修改，往往牵一发动全身，工程师需要花费更多的时间修改，效率低，质量也得不到保证。
   微服务化的优点体现不出来，反而放大了缺点。

缺乏微服务思维的团队，千万不要微服务，千万不要微服务，千万不要微服务。
不然技术团队很难做，产品团队也很难做。

产品的微服务思维

前面说了，微服务架构的核心思想是化繁为简，需要考虑两个步骤，先化整为零，把每个部分处理好后，再组合为一个整体。这两个步骤需要反复执行，不断优化。
产品的设计至少包含两部分，看的见的和看不见的。产品经理需要把产品拆散和抽象为最小单位产品-微产品，逐个打磨好，再组合在一起。而后续的升级也更多的是针对微产品。每个微产品都解决自己范围内的用户需求，有自己的功能清单，生命周期，微产品之间有清晰的边界和关系。
按这种思维设计的产品，技术实现就容易做的多了，因为大家站在一个维度上，讨论的东西更加具体了。一个微产品，技术部门对应用一个或者以上的微服务实现。对于微产品的功能升级，也只会影响到范围内的几个微服务。这是非常棒的产品团队。

下面开始介绍我们团队的实践过程。

产品目标

基于微信小程序实现一个互联网医疗平台，核心流程包含在线问诊、处方、支付和药品配送4个功能。

团队

总结我们团队的特点，也是很多小规模团队的共同特点。

1. 团队从零组建，成员流失率大，非常不稳定。
2. 预算有限，团队规模小，成员间专业水平差异大。
3. 与大厂团队比较，团队整体专业能力和经验都不足。
4. 工作压力大，常态加班，团队缺乏专门成长空间。

我们经过了大约2个月时间才形成了一个相对稳定的小团队。

• 产品+设计
  产品负责人1人。
  产品经理1人。
  高级设计师1人。
• 研发
  技术负责人1人。
  高级后端工程师1人。
  高级前端工程师1人。
  高级测试工程师1人。
  高级运维工程师 1人。
  后端工程师1人。
  前端工程师1人。

技术选型

我们是小团队，希望前后端统一开发语言，所以选择了JavaScript。

• 前端
  Taro 用于开发小程序。
  jm-ant-design-pro 基于Ant Design Pro 实现模块独立化及自动化加载，用于开发管理后台。
• 后端
  Node.js
  jm-ms 笔者自研的基于express，ws的微服务框架。
• 数据库
  mongodb
  mysql
  redis
  kafka
• 运维部署
  rancher + docker
  阿里云
• 工具
  git
  webstorm

过程管理

Scrum敏捷开发，团队协作工具：teambition。

总体设计

服务分层

产品的各个部分是有主次之分的，可以划分为核心业务和前台业务，通常20%的核心业务产生80%的价值。所以整个团队80%的主要力量应该投入到核心业务。
对于技术团队而言，除了关注业务分层，还要关心基础服务。
服务分层适用于所有角色，是确认各种任务优先级的依据。
总体来讲，共分为三层，如图所示。

image.png

1. 基础服务，按月更新
   关注安全性、可用性、可伸缩性、可扩展性、可管理性和经济性。
   主要提供基础能力，包括配置、权限、单点登陆、用户、护照、短信服务、验证码、消息队列、基础支付、路由等。
   这部分需求需要技术部门自己规划和升级，是技术负责人的重要责任。
2. 核心业务，按周更新
   这一层非常类似大厂的技术中台。
   关注安全性、可用性、可伸缩性、可扩展性、可管理性和经济性。
   对于业务进行高度抽象整理后，提炼出来的核心业务功能，包括业务用户、IM、产品、订单、供应商、支付等，沉淀了主要业务数据。
   这部分需求需要产品部门规划和升级，对于产品经理的经验和远见有很高的要求，决定了产品的结果。
3. 前台业务，按天更新
   关注可用性、可伸缩性。
   这部分业务非常灵活多变，需要快速实现，并且尽量保持接口不改或者少改。需求需要产品和运营部门规划和升级，尽量避免浪费。包含两种目的的工作
   • 组合基础服务和核心服务，必要的时候需要做少量开发工作，从而支持到具体的业务场景。
   • 对于尚未清晰的业务，进行试错性开发，快速验证业务可行性，验证成功后，重构为核心业务。

产品

限于篇幅，这里只讨论产品的核心业务流程。

需求分析

产品的目的，一个是收入，一个是提高就医效率。其中收入来源于问诊费和处方费用，都是由患者支付的。
分析核心流程后，可以拆分为5个微产品，分别是问诊、IM、处方、订单及支付。产生的数据包括医生、患者、问诊单、处方、IM消息、药品、订单及付款单。
这里需要注意的是，医生、患者和药品又可以拆分为3个微产品，其中医生、患者因为有共性，也可以作为一个微产品（用户）考虑，我个人建议分开，比较清晰。
对于每个微产品，都应该分别独立考虑，包括可见部分和不可见部分。同时考虑好与其他微产品的关系。
通常，良好的设计应该保证微产品之间的数据流是单向无循环的。

前端

包括小程序和管理后台，都发布为SPA。

后端

分层逻辑视图：

分层逻辑视图

按请求流程观察的逻辑视图：

请求逻辑视图

讨论

微产品和微服务是什么关系？

个人理解他们本质是相同的，分别从产品和技术人员的角度抽象和拆散同一一个业务。我认为团队协作的最好结果，就是产品和技术拆散的东西高度一致，只不过技术拆散的粒度可能更细。