小规模团队微服务架构实践如何做，看看这篇就知道了

序

网络上介绍微服务的文章很多，但是针对小规模团队如何实践微服务架构的文章很少，而照搬大公司的做法并不完全适合，很容易失败。

笔者在这个过程中也走过很多弯路，所以写了这篇文章，一方面做一个整理总结，更多的是希望能抛砖引玉，帮助他人，也被他人帮助。

本文通过公司一个近期的实际产品，从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%的主要力量应该投入到核心业务。

对于技术团队而言，除了关注业务分层，还要关心基础服务。 服务分层适用于所有角色，是确认各种任务优先级的依据。 总体来讲，共分为三层，如图所示。

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

产品

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

产品的目的，一个是收入，一个是提高就医效率。其中收入来源于问诊费和处方费用，都是由患者支付的。

分析核心流程后，可以拆分为5个微产品，分别是问诊、IM、处方、订单及支付。产生的数据包括医生、患者、问诊单、处方、IM消息、药品、订单及付款单。

这里需要注意的是，医生、患者和药品又可以拆分为3个微产品，其中医生、患者因为有共性，也可以作为一个微产品（用户）考虑，我个人建议分开，比较清晰。

对于每个微产品，都应该分别独立考虑，包括可见部分和不可见部分。同时考虑好与其他微产品的关系。

通常，良好的设计应该保证微产品之间的数据流是单向无循环的。

需求分析

产品的目的，一个是收入，一个是提高就医效率。其中收入来源于问诊费和处方费用，都是由患者支付的。

分析核心流程后，可以拆分为5个微产品，分别是问诊、IM、处方、订单及支付。产生的数据包括医生、患者、问诊单、处方、IM消息、药品、订单及付款单。

这里需要注意的是，医生、患者和药品又可以拆分为3个微产品，其中医生、患者因为有共性，也可以作为一个微产品（用户）考虑，我个人建议分开，比较清晰。

对于每个微产品，都应该分别独立考虑，包括可见部分和不可见部分。同时考虑好与其他微产品的关系。

通常，良好的设计应该保证微产品之间的数据流是单向无循环的。

前端

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

后端

分层逻辑视图：

分层逻辑视图

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

请求逻辑视图

作者：鱼哥2018 链接：https://www.jianshu.com/p/c636a1131277 来源：简书 简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。