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

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

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

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

产品

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

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

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

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

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

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

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

需求分析

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

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

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

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

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

前端

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

后端

分层逻辑视图:

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

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

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

版权声明

文章来源:https://www.jianshu.com/p/c636a1131277 作者:鱼哥2018

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论