SOA与微服务架构的对比
| 对比维度 | SOA | 微服务 |
|---|---|---|
| 服务粒度 | 粗 | 细 |
| 服务通信 | 重量级，ESB | 轻量级，如HTTP RESTful |
| 服务交付 | 慢 | 快 |
| 服务场景 | 企业级 | 互联网 |
两者是有相似点但本质不同的两种架构理念，两者都是通过服务的拆分来解决可扩展性问题，本质的不同在于几个核心理念的差别：是否有ESB、服务的粒度、架构设计的目标等。
微服务的坑
服务划分过细，服务之间关系复杂：
单个服务的复杂度下降，整个系统的复杂度上升，实际是把系统内的复杂度转移为系统间的复杂度。
服务数量太多，团队效率急剧下降：
一个简单的需求开发就需要涉及多个微服务，服务间的接口调用增多，增加接口设计以及测试，编译打包多个组件，调试部署多个程序。无论是开发、测试、部署和运维，都非常麻烦。
调用链太长，性能下降：
微服务之间通过HTTP调用，每次调用必须经过网络，一个用户操作可能需要经过几次的服务调用，如果一次调用网络响应时间50ms，6次就是300ms。为了支撑业务需求，就需要大幅增加硬件消耗。我所在项目产品，就从单体时代的8C24G消耗变成现在96C192G的资源消耗（当然，还有很大一部分资源是消耗在云平台自身上，服务器基础操作系统，虚拟化后虚机操作系统，容器自身的系统，以及云平台管理的代价）。
调用链太长，问题定位困难：
微服务数量太多，定位真正造成问题的原因复杂度增加很多，云平台下不管是从日志获取到命令操作，难度都加大，对开发人员的技能要求也非常大。
没有自动化支撑，无法快速交付：
从云基础环境的搭建（如一个OpenStack的搭建就涉及从底层的硬件到组网到操作系统的搭建再到组件的部署）到微服务产品系统的部署，是一个非常大的工程，没有自动化部署支撑是难以想象的，同时大量的接口需要自动化测试，大量的微服务需要自动化监控，理论上需要投入至少20%的人力在自动化上面。
没有服务治理，微服务数量多了后台管理混乱：
服务路由、服务故障隔离、服务注册和发现都必不可少。
另外，微服务的架构复杂，对人力技能要求变高，单人的生产力下降，人均可维护功能下降，相同功能的人力消耗变多。人的变多，交流的成本也会增加，整体会呈恶化状态，对于中小型企业（500人以下规模）需要慎重选择。
微服务填坑指南
服务粒度：基于团队规模拆分。设计和开发阶段，以3个人力一个微服务的粒度进行。
拆分方法：基于业务逻辑、可扩展性、可靠性、性能等多维度考虑。
以下基础设施必不可少：
| 基础设施 | 说明 |
|---|---|
| 服务发现 | 自理式：微服务自己注册被发现，代理式：负载均衡系统来完成服务发现（代理式） |
| 服务路由 | 确定访问服务的哪个节点，微服务内部实现（自理式）or负载均衡实现 |
| 服务容错 | 重试、流控、服务隔离 |
| 服务监控 | 收集信息并分析、预警 |
| 服务跟踪 | 标注点、跟踪树和span，采样跟踪、染色跟踪 |
| 服务安全 | 接入安全、数据安全、传输安全 |
| 自动化部署 | 版本管理、资源管理、环境管理、部署操作、升级回退 |
| 自动化测试 | 单元测试、集成测试、系统间接口测试 |
| 配置中心 | 微服务资源、依赖，版本配置，增删改查、节点管理，配置同步，推送 |
| 接口框架 | 协议统一（REST/RPC）,数据类型同一（json/xml）,数据规范统一 |
| API网关 | 统一的API网关，负责外部系统的访问操作，接入鉴权、权限控制、传输加密、请求路由、流量控制 |
