微服务和 SOA（面向服务架构）区别

相同点

1. 需要 Registry，实现动态的服务注册发现机制；
2. 需要考虑分布式下面的事务一致性，CAP 原则下，两段式提交不能保证性能，事务补偿机制需要考虑；
3. 同步调用还是异步消息传递，如何保证消息可靠性？SOA 由 ESB（企业服务总线） 来集成所有的消息；
4. 都需要统一的 Gateway 来汇聚、编排接口，实现统一认证机制，对外提供 APP 使用的 RESTful 接口；
5. 同样的要关注如何在分布式下定位系统问题，如何做日志跟踪，如电信的信令跟踪

差别点？

1. 是持续集成、持续部署？对于 CI、CD（持续集成、持续部署），这本身和敏捷、DevOps 是交织在一起的，这更倾向于软件工程的领域而不是微服务技术本身；
2. 使用不同的通讯协议是不是区别？微服务的标杆通讯协议是 RESTful，而传统的 SOA 一般是 SOAP，不过目前来说采用轻量级的 RPC 框架 Dubbo、Thrift、gRPC 非常多，在 Spring Cloud 中也有 Feign 框架将标准 RESTful 转为代码的 API 这种仿 RPC 的行为，这些通讯协议不应该是区分微服务架构和 SOA 的核心差别；
3. 是流行的基于容器框架还是虚拟机为主？Docker 和虚拟机还是物理机都是架构实现的一种方式，不是核心区别；

微服务架构的精髓在切分

1. 服务的切分上有比较大的区别，SOA 原本是以一种“集成”技术出现的，很多技术方案是将原有企业内部服务封装为一个独立进程，这样新的业务开发就可重用这些服务，这些服务很可能是类似供应链、CRM 这样的非常大的颗粒；而微服务这个“微”，就说明了他在切分上有讲究，不妥协。无数的案例证明，如果你的切分是错误的，那么你得不到微服务承诺的“低耦合、升级不影响、可靠性高”之类的优势，而会比使用 Monolithic 有更多的麻烦。
2. 不拆分存储的微服务是伪服务：在实践中，我们常常见到一种架构，后端存储是全部和在一个数据库中，仅仅把前端的业务逻辑拆分到不同的服务进程中，本质上和一个 Monolithic 一样，只是把模块之间的进程内调用改为进程间调用，这种切分不可取，违反了分布式第一原则，模块耦合没有解决，性能却受到了影响。

分布式设计第一原则 — “不要分布你的对象”

1. 微服务的“Micro”这个词并不是越小越好，而是相对 SOA 那种粗粒度的服务，我们需要更小更合适的粒度，这种 Micro 不是无限制的小
2. 一个简单的图书管理系统肯定无需微服务架构。既然采用了微服务架构，那么面对的问题空间必然是比较宏大，比如整个电商、CRM