同样是笔记摘录自---极客时间 李运华 《从0开始学架构》。
1、微服务和SOA比较
因为两者互相联系、互相区别。首先要区分出来。流行观点有：a、微服务是SOA的一种实现形式；b、微服务是SOA去掉ESB，就是一种轻量级的SOA；c、两者是看起来相似实质上有本质不同的架构模式。
前面博客里面，王磊的笔记有记录，他的观点是a。但本文作者理解是：SOA是基于解决企业的不同系统如何集成提出来的架构模式，是一种重模式，解决的是已有系统的集成，也确实是重量级的，强调的是兼容；微服务是基于互联网发展，在快速交付、基于web的敏捷环境下发展起来，粒度更小，交付更快，基于HTTP模式来通信，强调的是去耦和快速交付。
2、微服务拆分原则
微服务常见的焦油坑（业务陷阱）
- 服务划分过细，服务间关系复杂
- 服务数量太多，团队工作效率急速降低
- 调用链太长，性能低下
- 调用链太长，问题难定位
- 没有自动化支撑，难以快速交付
- 没有服务治理，服务数量多了后管理混乱
概括起来就是：
·微服务拆分过细，过分强调 small” ．
·微服务基础设施不健全，忽略了automated ” ．
·微服务并不轻量级，规模大了后，lightweight 不再适应．
其实说穿了，就是微服务数量太多，带来的复杂度问题。所以要根据技术团队成员数量和能力来划分微服务，而不是机械地划分得越多越好。作者提出“三个火枪手”原则，一个小组3个人。拆分的方法原则有：
a）根据业务逻辑划分（最常见：各管一件事）
b）根据扩展性划分（需求变动可能大的和比较稳定的分开）
c）根据可靠性、可用性要求来分（核心业务、非核心业务，参见异地多活设计要求）
d）根据性能要求拆分（把瓶颈拆出来）
一般大的项目和团队，要根据上述原则综合评估来划分。
3、微服务基础设施
显然，微服务顺应敏捷理念在互联网领域野蛮生长是有原因的。快速交付的背后是Devops等，支撑的不只是理念，还有一系列基础设施：
基础设施搭建优先级：
1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施．
2.接口框架、API网关：主要是为了提高开发效率，接口框架是提升内部服务的开发效率，API
网关是为了提升与外部服务对接的效率．
3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率．
4. 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率．
以上 3 和 4 两类基础设施，重要性会随着微服务节点数量增加而越来越重要，但在微服务节 点数量较少的时候，可用人工的方式支撑，虽然效率不高，但也基本能够顶住。
现在一般都使用SpringCloud全家桶。