踩过坑才懂：微服务架构设计的反常识真相
去年帮一家创业公司拆单体，拆完上线崩了三天。赔了小十万违约金。说起来都是泪。
这几年微服务被吹上了天，好像你一个做业务的公司不用微服务，就是技术落后，就是跟不上潮流。可真下场去做，十个里面有八个踩坑，还有一个直接把项目做黄了。
单体应用与微服务架构适用场景对比表
你别说，我之前还真见过五个人的团队拆八个微服务，问他们为什么，答曰“提前布局，为未来做准备”。等你业务做到那个规模再布局不行吗？三年后你公司还在不在都不好说，提前布局个啥啊。
微服务依赖调用链路拓扑图
我现在做架构设计，第一要求就是，每个服务对外暴露的接口不能超过20个，依赖的其他服务不能超过3个。超过就要重新划边界。
多出来的依赖，要么合并服务，要么把逻辑下沉到公共组件，要么做业务逻辑下沉，就是不能让一个服务串七八个调用，那不是微服务，那就是给埋雷。
适度拆分，轻量化才是现在微服务的主流方向
前几年搞微服务，风气就是越细越好，越多越好，一个大公司拆几千个服务，恨不得每个接口都做成一个服务。
你看这两年大厂的分享风向变了吧？开始说“适度拆分”，开始合并服务，开始提倡轻量化微服务了。
去年阿里云原生大会上，阿里的技术专家分享说，他们内部很多边界模糊的服务都合并了，整体调用量降了超过25%，平均响应时间快了近40%，运维成本直接砍半。
美团更早，前年底就提了“小团队，粗粒度服务”，反对无意义的过度拆分。
说白了，大家都是踩过坑之后，终于明白过来了。
对于大多数公司来说，真要做微服务，没必要一步到位搞什么全拆分，搞服务网格，你可以先做半微服务架构：先拆部署，不拆数据，共享同一个数据库，先把不同业务线的部署解耦，你发你的版，我发我的版，不互相影响，等业务真的大了，再慢慢拆分数据库，一点点来。
这样做的好处是什么？风险低，成本低，就能快速拿到微服务的好处，又不用承担全拆分的各种问题。
很多人说K8s和Istio是微服务的标配，扯淡。我见过好多十几二十个服务的公司，用Docker Compose加Nginx做负载，跑的好好的，稳定的很，成本还低。
你服务才十几个，上Istio干嘛？光sidecar的CPU消耗就占了20%，光配置就要花掉一个运维半个月的时间，性价比在哪？
不过话说回来，真当你业务起来了，团队过百了，服务过百了，该上的还是得上。核心就是，你别为了技术而技术，别为了赶潮流而上新技术，所有的架构设计，都要匹配你当前的阶段和成本。
我见过最舒服的微服务，是一个三十多人的电商团队，只拆了三个服务：用户内容、交易履约、供应链管理，每个服务配一个八到十人的小组，边界清晰，责任明确，独立迭代，三年没出过大问题，每个月能稳定发六个版本，比那些拆了二三十个服务天天排障的舒服一万倍。
技术从来都是服务业务的，不是用来撑门面的。微服务架构设计，拼的从来不是你用了多少牛逼的新技术，拼的是你能不能找准自己的位置，做最合适的设计。
那些上来就给你讲一套标准流程，告诉你必须按这个来做的，要么是没踩过坑的新手，要么就是卖课的。别信。
别上来就拆，90%的中小公司根本不需要微服务
说实话，我接触过的项目里，至少八成喊着要做微服务的公司，根本没搞懂自己为什么要做微服务。 老板听行业峰会嘉宾说微服务能扩能缩，能支撑亿级流量，回来就要求技术部三个月改完架构。技术leader不好意思说自己不懂，硬着头皮上，最后烂摊子留给全团队擦屁股。 微服务解决的核心问题，是大规模团队的协作效率问题。你一个十个人的小团队，整个项目代码加起来不到十万行，一个礼拜就能全量回归测试完，拆什么微服务？ 单个功能发版要协调三四个团队，联调就要花掉一半时间，原来两周上线一个版本，现在两个月都出不来，纯属没事找事。单体应用与微服务架构适用场景对比表
你别说，我之前还真见过五个人的团队拆八个微服务，问他们为什么，答曰“提前布局，为未来做准备”。等你业务做到那个规模再布局不行吗？三年后你公司还在不在都不好说，提前布局个啥啊。
微服务架构设计的核心，根本不是拆服务，是治依赖
很多人对微服务的误解，就是把原来的单体代码按模块切成好几个，分别部署，就叫微服务了。 实际上这么切完，你得到的不是微服务，是一个分布式单体。比原来的单体难用一百倍。 我前年碰过一个电商项目，原来的单体跑的好好的，非要拆成用户、订单、商品、支付、物流、营销六个服务。拆完之后，下单流程要依次调用用户验权、商品查库存、营销算优惠、支付扣余额、物流算运费五个远程调用。 只要其中一个服务出问题，下单直接失败。原来单体里都是本地方法调用，出问题直接回滚，现在分布式事务搞不定，出问题就是脏数据，只能半夜起来手动改数据库，苦不堪言。 为什么会这样？因为拆服务的时候根本没理清楚依赖关系，只顾着切代码，把强耦合的拆到不同服务里，可不就乱了么。 微服务架构设计里，第一步要做的永远是划清领域边界，把高度耦合的逻辑放在同一个服务里，让服务之间的依赖尽可能少，尽可能弱。微服务依赖调用链路拓扑图
我现在做架构设计，第一要求就是，每个服务对外暴露的接口不能超过20个，依赖的其他服务不能超过3个。超过就要重新划边界。
多出来的依赖，要么合并服务，要么把逻辑下沉到公共组件，要么做业务逻辑下沉，就是不能让一个服务串七八个调用，那不是微服务，那就是给埋雷。
适度拆分，轻量化才是现在微服务的主流方向
适度拆分，轻量化才是现在微服务的主流方向
前几年搞微服务，风气就是越细越好，越多越好，一个大公司拆几千个服务，恨不得每个接口都做成一个服务。
你看这两年大厂的分享风向变了吧？开始说“适度拆分”，开始合并服务，开始提倡轻量化微服务了。
去年阿里云原生大会上，阿里的技术专家分享说，他们内部很多边界模糊的服务都合并了，整体调用量降了超过25%，平均响应时间快了近40%，运维成本直接砍半。
美团更早，前年底就提了“小团队，粗粒度服务”，反对无意义的过度拆分。
说白了，大家都是踩过坑之后，终于明白过来了。
对于大多数公司来说，真要做微服务，没必要一步到位搞什么全拆分，搞服务网格，你可以先做半微服务架构：先拆部署，不拆数据，共享同一个数据库，先把不同业务线的部署解耦，你发你的版，我发我的版，不互相影响，等业务真的大了，再慢慢拆分数据库，一点点来。
这样做的好处是什么？风险低，成本低，就能快速拿到微服务的好处，又不用承担全拆分的各种问题。
很多人说K8s和Istio是微服务的标配，扯淡。我见过好多十几二十个服务的公司，用Docker Compose加Nginx做负载，跑的好好的，稳定的很，成本还低。
你服务才十几个，上Istio干嘛？光sidecar的CPU消耗就占了20%，光配置就要花掉一个运维半个月的时间，性价比在哪？
不过话说回来，真当你业务起来了，团队过百了，服务过百了，该上的还是得上。核心就是，你别为了技术而技术，别为了赶潮流而上新技术，所有的架构设计，都要匹配你当前的阶段和成本。
我见过最舒服的微服务，是一个三十多人的电商团队，只拆了三个服务：用户内容、交易履约、供应链管理，每个服务配一个八到十人的小组，边界清晰，责任明确，独立迭代，三年没出过大问题，每个月能稳定发六个版本，比那些拆了二三十个服务天天排障的舒服一万倍。
技术从来都是服务业务的，不是用来撑门面的。微服务架构设计，拼的从来不是你用了多少牛逼的新技术，拼的是你能不能找准自己的位置，做最合适的设计。
那些上来就给你讲一套标准流程，告诉你必须按这个来做的，要么是没踩过坑的新手，要么就是卖课的。别信。