微服务架构到底该怎么挑选才不会踩坑，适合自己项目的那些事儿

（来源：多位一线架构师的经验分享与技术社区讨论）

挑微服务,这事儿就跟找对象一样，不能光看别人说好你就上，得看合不合适，别人嘴里高大上的“白富美”，娶回家你可能养不起也处不来，咱今天不整那些虚头巴脑的专业名词，就唠点实在的，怎么选才不踩坑。

第一，先问问自己：我的项目真的需要微服务吗？

这是最最最重要的一步,也是最多人栽跟头的地方，很多人是冲着“微服务”这个时髦词去的，觉得不用就落后了，但微服务不是银弹，它解决的是“复杂性问题”。

• 如果你的项目是： 一个新启动的小应用，业务逻辑简单，团队就三五个人，开发速度要求高，那你千万别用微服务！老老实实用单体架构（就是把所有功能打包在一个应用里），开发快、部署简单、调试方便，这时候上微服务，纯粹是自找麻烦，你会被服务拆分、网络通信、分布式事务等一系列问题搞得焦头烂额。（来源：Martin Fowler 关于微服务适用性的论述）
• 什么时候才真的需要考虑微服务呢？ 当你的单体应用变成了一个几十万行代码的“大泥球”，动一发牵全身，改个小功能都要测试整个系统，部署一次要半小时，各个模块团队之间成天“打架”，这时候，微服务带来的“独立开发、独立部署、技术选型灵活”等好处，才能抵消它带来的复杂度，简单说，就是当“管理人的复杂度”超过了“管理技术的复杂度”时，微服务才值得考虑。

第二，如果确定要用了，怎么拆？这是第二个大坑。

拆不好,微服务就变成了“微混乱”，拆分的原则不是技术，而是业务。

• 别按技术层拆： 比如把所有的“数据库操作”拆成一个服务，所有的“业务逻辑”拆成另一个服务，这是最糟糕的拆法，它会让服务之间产生严重的依赖，比单体架构还糟糕。
• 要按业务能力拆：（来源：DDD领域驱动设计的思想） 也就是围绕公司的核心业务领域来拆，比如一个电商系统，可以拆成“用户服务”、“商品服务”、“订单服务”、“支付服务”，每个服务都负责自己领域内的所有事情，从数据存储到业务逻辑再到对外接口，这样拆，服务之间界限清晰，团队可以围绕一个完整的业务领域工作，效率最高，怎么找到这些业务领域？需要你和业务人员坐下来好好聊，画图，搞清楚业务的核心概念和流程。

第三，技术选型别贪多求新，稳定压倒一切。

微服务生态圈里的工具多如牛毛,服务发现、配置中心、API网关、熔断器、链路追踪……每个类别都有十几个开源项目等着你。

• 新手陷阱： 容易犯的错误是，哪个最新、哪个最火就用哪个，结果可能就是掉进坑里，因为新技术可能文档不全、社区不成熟、隐藏的Bug多。
• 稳妥的做法：
  1. 首选有强大商业支持和成熟社区的产品： 比如Spring Cloud生态（对于Java技术栈），虽然它可能有点“重”，但资料多、案例多，你遇到的问题大概率别人都遇到过，容易找到解决方案。
  2. 评估团队的技术能力： 如果团队里都是大神，喜欢折腾，可以尝试一些更轻量、更前沿的技术，比如基于Go的微服务框架，但如果团队对新技术不熟，强行上新框架，学习成本和排错成本会非常高。
  3. 从简入手： 刚开始，不一定非要上全所有的组件，可以先从最核心的服务注册发现（比如Nacos、Eureka）和配置管理开始，保证服务能跑通，等业务量上来了，再逐步引入网关、熔断等保障稳定性的组件。

第四，想清楚运维和监控的成本。

微服务意味着服务实例的数量成倍增加,以前你只需要监控一个应用，现在要监控几十个甚至上百个服务。

• 部署： 手动部署是不可能的了，必须要有自动化的CI/CD（持续集成/持续部署）流水线，这块需要投入资源搭建和维护。
• 监控和排错：（来源：谷歌SRE运维经验的普及） 当用户报障说“页面打不开了”，在单体应用里，你可能查一个日志文件就行，但在微服务里，一个请求可能经过了五六个服务，你需要有“链路追踪”工具，能像查案一样，把这个请求在所有服务中的足迹串联起来，快速定位是哪个环节出了问题，没有完善的监控体系，微服务系统出了问题就是一场灾难。

怎么选才不会踩坑：

1. 动机要对： 别为了微服务而微服务，业务和团队规模没到那儿，就别折腾。
2. 拆分要准： 跟着业务走，别跟着技术感觉走。
3. 技术要稳： 选择团队能hold住的、社区成熟的技术栈，别盲目追新。
4. 运维要狠： 提前规划好自动化部署、监控告警体系，不然上线就是噩梦的开始。

微服务架构的本质是一种组织架构和分工方式的技术体现,它的目标是提升大规模团队的协作效率和系统的长期可维护性，如果你的项目没到这个阶段，那么选择一个良好的单体架构，并把它设计得足够模块化，才是最适合、最明智的选择。