SOA与微服务架构的对比

两者是有相似点但本质不同的两种架构理念，两者都是通过服务的拆分来解决可扩展性问题，本质的不同在于几个核心理念的差别：是否有ESB、服务的粒度、架构设计的目标等。

微服务的坑

服务划分过细，服务之间关系复杂：
单个服务的复杂度下降，整个系统的复杂度上升，实际是把系统内的复杂度转移为系统间的复杂度。
服务数量太多，团队效率急剧下降：
一个简单的需求开发就需要涉及多个微服务，服务间的接口调用增多，增加接口设计以及测试，编译打包多个组件，调试部署多个程序。无论是开发、测试、部署和运维，都非常麻烦。
调用链太长，性能下降：
微服务之间通过HTTP调用，每次调用必须经过网络，一个用户操作可能需要经过几次的服务调用，如果一次调用网络响应时间50ms，6次就是300ms。为了支撑业务需求，就需要大幅增加硬件消耗。我所在项目产品，就从单体时代的8C24G消耗变成现在96C192G的资源消耗（当然，还有很大一部分资源是消耗在云平台自身上，服务器基础操作系统，虚拟化后虚机操作系统，容器自身的系统，以及云平台管理的代价）。
调用链太长，问题定位困难：
微服务数量太多，定位真正造成问题的原因复杂度增加很多，云平台下不管是从日志获取到命令操作，难度都加大，对开发人员的技能要求也非常大。
没有自动化支撑，无法快速交付：
从云基础环境的搭建（如一个OpenStack的搭建就涉及从底层的硬件到组网到操作系统的搭建再到组件的部署）到微服务产品系统的部署，是一个非常大的工程，没有自动化部署支撑是难以想象的，同时大量的接口需要自动化测试，大量的微服务需要自动化监控，理论上需要投入至少20%的人力在自动化上面。
没有服务治理，微服务数量多了后台管理混乱：
服务路由、服务故障隔离、服务注册和发现都必不可少。

另外，微服务的架构复杂，对人力技能要求变高，单人的生产力下降，人均可维护功能下降，相同功能的人力消耗变多。人的变多，交流的成本也会增加，整体会呈恶化状态，对于中小型企业（500人以下规模）需要慎重选择。

微服务填坑指南

服务粒度：基于团队规模拆分。设计和开发阶段，以3个人力一个微服务的粒度进行。
拆分方法：基于业务逻辑、可扩展性、可靠性、性能等多维度考虑。
以下基础设施必不可少：