标签：快速 有一个 依赖 个人 地产 结果 就是 inf 营销
1. 前言
microservices
其实微服务已经不算很火的概念了，它已经成为了面试的主角。很多同学私下问胖哥要一些微服务的资料，大部分都是为了面试。有时候想想这很悲哀。今天就讲几个我知道的案例，欢迎对号入座。
配图与现实无关
某教育初创公司，2018 年项目立项就使用了当时火热的SpringCloud。当时的团队只有 12 个人，其中后台开发只有 3 个人，在这样的情况下却采用了微服务架构。前期业务的设计不合理，导致项目的业务边界不清晰，随着业务迭代出现了大量业务耦合，为了获取一个完整的数据不得不进行数十个服务间的调用。同时因为使用了分布式，数据的一致性、服务的可用性等重要指标得不到保证，拖累了整个开发组，最终拖死了这个项目。朋友说起这个事唏嘘不已，本来这个项目按部就班还是有希望做出一些成绩的。
从这个案例中，管理层低估了微服务开发的复杂性，甚至就是为了“赶时髦”。没有考虑团队是否准备好了，能否从容对一些不确定因素。胖哥一直坚信微服务不是面对初创项目和三五个人的技术团队的，初创项目缺乏用户量，用微服务就是大材小用，更多的精力应该放在业务推广扩展上去。
某传统行业 IT 研发部门，相比较上面团队要大很多，业务也比较成熟。但是在落地微服务架构的前期也出现了问题，首先也存在业务界划分不清的问题，其次微服务的项目依赖管理混乱，没有一个集中式的依赖池，造成后期迭代经常出现兼容性问题。团队依然是“大兵团”作战，没有根据业务拆分成微服务小组，一些决策权也没有下沉，跟不上快速迭代的步子。项目越做越复杂，进度越来越慢，最终拖了业务的后腿。不过幸亏及时改正了上面的大部分问题，避免被拖入了微服务的“泥潭”。
前年某地产线上营销团队邀请我入伙，说要上微服务，希望我可以参与进来，但是从谈话中感觉他对微服务的理解仅仅是把服务拆开的一个层面，这让我感到不安，最终就没有应邀，不清楚现状如何。
胖哥认为一个要做微服务的团队由没有微服务经验的人来领导，那么结果只会流于表面，仅仅是使用了一些微服务的解决方案，潜在的各种性能问题、扩展性问题、可用性问题都没有洞察到。架构是服务于业务的，架构是需要实践的，架构是演进而来的，不能单单只学了几个框架，看了几篇文章，就信心满满搞微服务。
什么时候该用微服务？胖哥认为一个最要的指标就是业务体量规模达到一个量级，或者业务目标非常明确，已经可以预计未来的规模，而当前的架构即将成为瓶颈时再考虑微服务；或者当前的团队技术实力，业务拆分能力出众，公司具备微服务实施的开发环境，具有科学的管理流程时先在一些边缘业务试试水评估一下。
要记住架构服务于业务，微服务不是银弹，不要为了微服务而微服务。
标签：快速 有一个 依赖 个人 地产 结果 就是 inf 营销
原文地址：https://blog.51cto.com/14901317/2523044
