社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
网络上介绍微服务的文章很多，但是针对小规模团队如何实践微服务架构的文章很少，而照搬大公司的做法并不完全适合，很容易失败。
笔者在这个过程中也走过很多弯路，所以写了这篇文章，一方面做一个整理总结，更多的是希望能抛砖引玉，帮助他人，也被他人帮助。
本文通过公司一个近期的实际产品，从0到1介绍设计和实现的过程。
限于个人的能力和经验，难免有不足之处，所以诚惶诚恐，希望得到大家的指正。
思想的高度决定行动的水平，我理解的微服务应该是这样的。
整个团队包括产品、设计、研发、测试、运维都应该具备微服务思维。
整个团队包括产品、设计、研发、测试、运维都应该具备微服务思维。
整个团队包括产品、设计、研发、测试、运维都应该具备微服务思维。
重要的事情说三遍。
既然是一种思想，首先的，整个团队要统一认识。
对于微服务，经常有一个认识上的误区，产品和设计只关注完整的业务流程和输出高保真，微服务化的工作交给技术去做。这是很多团队失败的重要原因，我们也犯过同样的错误。其导致的问题包括：
缺乏微服务思维的团队，千万不要微服务，千万不要微服务，千万不要微服务。
不然技术团队很难做，产品团队也很难做。
前面说了，微服务架构的核心思想是化繁为简，需要考虑两个步骤，先化整为零，把每个部分处理好后，再组合为一个整体。这两个步骤需要反复执行，不断优化。
产品的设计至少包含两部分，看的见的和看不见的。产品经理需要把产品拆散和抽象为最小单位产品-微产品，逐个打磨好，再组合在一起。而后续的升级也更多的是针对微产品。每个微产品都解决自己范围内的用户需求，有自己的功能清单，生命周期，微产品之间有清晰的边界和关系。
按这种思维设计的产品，技术实现就容易做的多了，因为大家站在一个维度上，讨论的东西更加具体了。一个微产品，技术部门对应用一个或者以上的微服务实现。对于微产品的功能升级，也只会影响到范围内的几个微服务。这是非常棒的产品团队。
下面开始介绍我们团队的实践过程。
基于微信小程序实现一个互联网医疗平台，核心流程包含在线问诊、处方、支付和药品配送4个功能。
总结我们团队的特点，也是很多小规模团队的共同特点。
我们经过了大约2个月时间才形成了一个相对稳定的小团队。
我们是小团队，希望前后端统一开发语言，所以选择了JavaScript。
Scrum敏捷开发，团队协作工具：teambition。
产品的各个部分是有主次之分的，可以划分为核心业务和前台业务，通常20%的核心业务产生80%的价值。所以整个团队80%的主要力量应该投入到核心业务。
对于技术团队而言，除了关注业务分层，还要关心基础服务。
服务分层适用于所有角色，是确认各种任务优先级的依据。
总体来讲，共分为三层，如图所示。
限于篇幅，这里只讨论产品的核心业务流程。
产品的目的，一个是收入，一个是提高就医效率。其中收入来源于问诊费和处方费用，都是由患者支付的。
分析核心流程后，可以拆分为5个微产品，分别是问诊、IM、处方、订单及支付。产生的数据包括医生、患者、问诊单、处方、IM消息、药品、订单及付款单。
这里需要注意的是，医生、患者和药品又可以拆分为3个微产品，其中医生、患者因为有共性，也可以作为一个微产品（用户）考虑，我个人建议分开，比较清晰。
对于每个微产品，都应该分别独立考虑，包括可见部分和不可见部分。同时考虑好与其他微产品的关系。
通常，良好的设计应该保证微产品之间的数据流是单向无循环的。
包括小程序和管理后台，都发布为SPA。
分层逻辑视图：
按请求流程观察的逻辑视图：
个人理解他们本质是相同的，分别从产品和技术人员的角度抽象和拆散同一一个业务。我认为团队协作的最好结果，就是产品和技术拆散的东西高度一致，只不过技术拆散的粒度可能更细。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
