35 | 微服务架构最佳实践 - 方法篇

李运华



该思维导图由 AI 生成，仅供参考

专栏上一期，我谈了实施微服务需要避免踩的陷阱，简单提炼为：
微服务拆分过细，过分强调“small”。
微服务基础设施不健全，忽略了“automated”。
微服务并不轻量级，规模大了后，“lightweight”不再适应。
针对这些问题，今天我们看看微服务最佳实践应该如何去做。我会分两期介绍这部分内容，今天是微服务架构最佳实践的方法篇，下一期是基础设施篇。
服务粒度针对微服务拆分过细导致的问题，我建议基于团队规模进行拆分，类似贝索斯在定义团队规模时提出的“两个披萨”理论（每个团队的人数不能多到两张披萨都不够吃的地步），分享一个我认为微服务拆分粒度的“三个火枪手”原则，即一个微服务三个人负责开发。当我们在实施微服务架构时，根据团队规模来划分微服务数量，如果业务规继续发展，团队规模扩大，我们再将已有的微服务进行拆分。例如，团队最初有 6 个人，那么可以划分为 2 个微服务，随着业务的发展，业务功能越来越多，逻辑越来越复杂，团队扩展到 12 个人，那么我们可以将已有的 2 个微服务进行拆分，变成 4 个微服务。
为什么是 3 个人，不是 4 个，也不是 2 个呢？
首先，从系统规模来讲，3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度；如果是 2 个人开发一个系统，系统的复杂度不够，开发人员可能觉得无法体现自己的技术实力；如果是 4 个甚至更多人开发一个系统，系统复杂度又会无法让开发人员对系统的细节都了解很深。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

微服务架构的最佳实践方法是实施微服务架构的关键。文章首先提出了“三个火枪手”的原则，即一个微服务由三个人负责开发，以此来规划微服务的粒度。其次，介绍了几种常见的微服务拆分方法，包括基于业务逻辑、可扩展性、可靠性和性能等方面的拆分方式。强调了拆分微服务时需要根据团队规模和业务需求来确定合适的服务数量和职责范围，避免拆分过粗或过细的情况。此外，还强调了拆分微服务的好处，包括提升项目快速迭代的效率、避免影响已有成熟功能、保证核心服务的高可用性和降低高可用成本等方面的优势。另外，文章还介绍了微服务基础设施的重要性，包括服务发现、服务路由、服务容错、接口框架、API网关、自动化部署、自动化测试、配置中心、服务监控、服务跟踪和服务安全等功能。最后，鼓励读者思考自身业务微服务架构是否还有改进和提升的空间。整体而言，本文通过介绍微服务架构的最佳实践方法，为读者提供了在实施微服务架构时应该注意的关键点和方法，有助于读者更好地理解和应用微服务架构。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学架构》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(77)

最新
精选

云学
这篇很实用，谢谢分享
作者回复: 仅此一家，别无分店，都是我自己思考出来的😄
2018-07-17

130
herist
感谢老师对微服务解读，有3个问题：目前公司有个在线交易系统，大概几百个表的单体服务项目，其他业务前端都远程调用这个项目，现在想做微服务的改造。 1、实施微服务按业务职责划分后，是否对应模块的数据库也必须要独立？ 2、若为每个微服务项目都拆出来新的数据库，原来各业务间的数据依赖（单库的时候Join查询就ok了），拆分多个项目后，有何好的处理办法？ 3、团队开发时的问题，由于每小团队负责一个微服务，但开发时需要访问其他微服务，应该有个开发环境负责集成大家提交的代码，构建新版本供其他团队调用和调试，即：开发团队都可以作为消费者访问服务器上微服务（互通），但是开发人员本机启动调试时，不能注册到这台服务器（隔离），这块如何能很好解决？
作者回复: 1. 需要，微服务需要独立部署独立运行，数据库不拆分做不到这点 2. 参考专栏前面分库分表内容 3. 开发环境也可以搭建微服务，我们是三套环境：开发，测试，线上
2018-07-18
11
29
型火🔥
三个火枪手分前后端吗？
作者回复: 一般指后端人员，前端人员是多服务公用的，如果用node之类的系统，本身可以算一个独立的微服务
2018-07-18

14
赵武艺
看来小企业还是不太适合微服务架构，尤其是开发人员少的？
作者回复: 是的，等业务发展，人员规模大了再重构，90%以上的新业务还没发展就挂掉了😂😂
2018-07-17

12
王刚
听了老师的课对我自己有很大帮助，最近我们公司也在研究微服务～总感觉是一头雾水～希望老师多讲解一下关于微服务经常会涉及到的精髓！
作者回复: 本篇就是精髓😄😄
2018-07-18

9
Ivan
使用dubbo体系，开发微服务。那么一个微服务是指一个部署单元(jar or war)还是指一个暴露的接口？我的答案是部署单元。请老师帮忙解惑，谢谢！
作者回复: 一个可以独立部署和运行的子系统
2018-07-17

9
杨陆伟
为什么说配置中心可以提升测试和运维的效率，这里不是太理解
作者回复: 不用去几十台服务器几百个节点手工修改配置文件
2019-03-28

8
Geek_89bbab
那么对于像kafka，rabbitmq这样的对应的消费者服务的消费地址是否应该放置到配置中心动态配置？还是不建议动态修改？
作者回复: 任何配置都可以放配置中心，区别只是动态配置还是需要重启，中间件也不例外
2018-10-24

8
森林
这里有个先有鸡还是现有蛋的问题。究竟是先根据人数量决定服务数量，还是根据服务数量决定人的数量。就像文章里提到的，很多时候需要根据各种需求场景拆分服务，当生产确切不拆分就会导致问题时，应该反向以服务数量评估要扩招的人
作者回复: 招人的第一标准是业务有没有发展😄
2018-09-20
2
8
孙振超
咨询老师一个问题：在服务切分的时候会存两个系统间数据发生交集的情况，比如一个是设备系统，另一个是用户系统，用户的各项操作必然发生在设备上，这样就会存在设备和用户的各种关系和操作记录，像这样的数据设备系统和用户系统都希望以自己为准，而后对外提供相应的服务。如果是数据存储两份，设备系统存储设备和用户的关系，用户系统存储用户和设备的关系，那么在数据一致性和调用链路上就会变得复杂；如果只存储一份，放在那个系统上另一个系统都会有意见。对于此种情况，有什么比较好的解法？
作者回复: 其实你这句话已经包含了答案“用户操作必然发生在设备上”，这就是说设备是基础数据，用户和设备对应关系应该是用户系统管理的。还有一种判断标准是设备数据还可以给其它业务用，如果设备系统存储用户和设备对应关系，这个数据不是通用的，违背了设备系统的职责
2018-09-15

7

收起评论