踩过无数生产坑之后，我眼里实用的微服务架构设计
别为了微服务而微服务，拆分的核心从来不是粒度
很多新手做微服务架构设计，第一个误区就是追求越细越好。说什么「单一职责」，一个方法一个服务都能扯出来。我之前待的那家做跨境电商的创业公司，技术leader刚从大厂出来，满脑子都是先进架构，上来就要求按接口粒度拆，最后光订单相关的就拆出了八个服务。
结果呢？用户提交一个订单，要依次调用创建、库存扣减、价格计算、优惠核销、物流通知五个服务，随便一个服务超时，整个请求就失败。高峰期的时候，服务之间的调用超时率直接干到15%，客服电话被打爆。
错误微服务拆分后调用链示意图
拆分的第一核心原则，从来都是按业务边界拆分，不是按代码粒度拆分。一个业务域就是一个服务，边界清晰，改动不牵连其他域，这就够了。电商场景下，用户域、商品域、订单域、支付域，本来就是天然清晰的边界，拆成四个服务足够用，非要拆成二三十个，除了增加调用开销和排查难度，半毛钱用处都没有。对吧？
适合自己的，才是最好的设计
现在打开技术社区，随便搜微服务，满屏都是Service Mesh、Istio、可观测性这些高大上的名词，搞得很多人觉得不搞一套全的，就不是合格的微服务。
说实话，我见过十几个人的团队，硬上Istio搞服务网格，十个不到的服务，每个服务旁边跑个Sidecar，资源消耗直接涨了40%，出了问题官方文档都看不懂，最后花了一个月又拆了，折腾半天原地踏步。
微服务架构设计，从来不是堆技术组件，是解决你当下的问题。如果你是创业团队，业务还在快速迭代，服务数量不到十个，那一套Nacos+OpenFeign+Sentinel，足够搞定所有问题，轻量，开发上手快，出了问题随便搜都有解决方案。非要搞什么高大上的组件，纯属给自己找不痛快。
说到核心问题，绕不开容错和分布式事务。很多人上来就要搞强一致性分布式事务，非要上XA协议，结果性能掉了一半，用户打开页面等三秒，直接走了。百分之九十的中小业务场景，最终一致性完全够用，一个消息队列做补偿，足够解决百分之九十九的问题，性能还高，为什么非要搞那套复杂的强一致？
微服务核心容错机制处理流程图
去年帮一个朋友的生鲜平台梳理架构，他们原来为了强一致，把订单和库存的事务搞成了一个分布式强一致，高峰期qps上不去，后来改成了库存预扣+超时回补的最终一致，qps直接翻了三倍，稳定得很。
最容易被忽略的设计：运维和监控是活下去的关键
最容易被忽略的设计：运维和监控是活下去的关键
很多人做设计，把所有精力都放在拆分、服务调用、分布式事务这些东西上，完全忘了，微服务上线之后，运维和排查问题才是最大的成本。
我早年就吃过这个亏，拆完服务上线，出了问题，用户说下单失败，我和几个开发翻了四个小时日志，才发现是优惠服务的某个参数错了——日志散在五台服务器上，每个服务打自己的，连个统一查询的地方都没有，差点把眼睛看瞎。
做微服务架构设计的第一天，就要把统一日志、全链路监控、错误告警的位置留出来。哪怕一开始做的简单点，先搭好框架，也比后面出了问题再返工强太多。现在开源的工具很多，ELK搭日志，SkyWalking做链路追踪，都是现成的，花一两天搭好，能帮你省后面无数个通宵。
还有一个容易忽略的点，就是每个服务的独立扩容能力。微服务最大的好处就是哪个服务压力大，就扩容哪个，但是很多人设计的时候，把所有服务都扔在一个资源池里，大促的时候订单服务要扩容，把其他服务的资源都抢了，结果一起挂，这种低级错误，我真的见过不止一次。
不过话说回来，要是你的团队就三五个开发，一天总共也就几千个请求，老老实实写单体不行吗？非要拆什么微服务？省下的时间多改两个产品需求，多休息两天，不好吗？架构本来就是为业务服务的，不是拿来给技术人员贴金的。
说白了，架构设计就是取舍，你要换开发效率换伸缩性，就要接受额外的运维成本，没有完美的架构，只有适合你当前阶段的架构。微服务架构设计也一样，搞对拆分边界，选对适合自己的技术组件，提前留好监控运维的位置，比什么都强。