1、SOA（面向服务架构）
两个主流实现方式：webService和ESB
2、微服务的特性（对比传统单体架构，单体应用）
目标：致力于松耦合和高内聚的效果，人员和项目的职责单一！解决单体应用业务急剧增长所带来的问题
（1）单一功能放在单一服务中
（2）每个服务运行在单独的进程中
（3）每个服务应该有自己独享的数据库、缓存、消息队列等资源
（4）独享的运营人员（技术运维和业务运营），每个服务高度自治
（5）每个服务可以根据性能需求独立地进行水平伸缩，每个服务可以运行在容器化平台内，多实例运行，达到平滑伸缩的效果
3、微服务架构倡导去中心化的服务管理和治理，尽量不设置中心化管理服务。
最差也要在中心化管理服务宕机时有替代的解决方案和设计
4、微服务的交互模式
（1）消费者容错模式
推荐使用较为宽松的校验策略，即使服务消费者拿到的消息报文发生了改变，消费者也需要尽可能努力地提取需要的数据，忽略不可识别的数据。
（2）消费者驱动契约模式
提供者契约，消费者契约，消费者驱动契约
消费者驱动契约模式是定义服务化中服务之间交互接口改变的最佳规则。
一个消费者契约会成为提供者契约的一部分；多个服务消费者可以对服务提供者提出约束，服务提供者（生产者）需要在将来遵守服务消费者提出来的契约，这就是消费者驱动的契约。
（3）去数据共享模式
与SOA服务化对比，微服务是去ESB（企业服务总线），去中心化及分布式的；微服务之间交互通过定义良好的接口来实现，不允许使用共享数据来实现。
微服务设计中使用缓存或者数据库作为两个服务之间的纽带，这种实现方式是错误的，一定不要共享缓存和数据库等资源，也不要使用总线模式，服务之间通信和交互只能依赖定义良好的接口，通常使用restful样式的API或者透明的RPC调用框架。
5、微服务的分解和组合模式
（1）服务代理模式
根据业务需求，选择后端的某个服务，对服务返回结果加工或者直接返回调用方
（2）服务聚合模式
根据业务处理流程需要，以一定顺序调用多个服务，对服务返回的数据进行组合，加工和转换，最后以特定形式返回给调用方
（3）服务串联模式
串联服务调用服务一，服务一调用服务二，一层一层调用，建议层级不要太多，建议优先使用服务聚合模式，通过聚合服务，业务流程调用各个服务。
（4）服务分支模式
是以上模式相结合的产物，调用后端多个服务或者服务串联链，然后将结果返回给调用方
（5）服务异步消息模式
以上的组合模式都是使用restful风格的同步调用实现，容易导致调用过程阻塞线程。
需要梳理核心系统的最小化服务集合，这些核心系统服务采用同步调用，而其他核心链路以外的服务可以使用异步消息队列进行异步化。
（6）服务共享数据模式
只有两个场景需要用到这种模式
①单元化架构（对性能要求高的平台，通过网络通信会对性能方面有损耗）
②遗留的整体服务（历史遗留的传统单体服务，在重构微服务过程中，表耦合比较强，数据表才分需要进行反规范化处理，会导致数据一致性的问题，可以暂时共享数据缓存）
6、微服务的容错模式
通过网络通信的远程调用，我们知道网络通信是不稳定、不可靠的，一个服务依赖的服务可能出错、超时、或者宕机，如果没有及时发现和隔离问题，那么很可能在短时间内服务的线程池中的线程被用满、资源耗尽，导致出现雪崩效应。解决方案：
（1）舱壁隔离模式
①微服务容器分组
普通用户容器池，vip用户（大部分商户）核心服务容器池
②线程池隔离
将多个功能混合部署到一个微服务中，然后不同功能使用不同的线程池，避免线程堵塞
（2）熔断模式
熔断检测，当服务的输入负载迅速增加时，对负载进行熔断。
（3）限流模式
评估服务的最大性能和容量
①计数器
②令牌桶（流行的实现限流的技术方案）
通过一个线程在单位时间内生产固定数量的令牌，然后把令牌放到队列中，每次请求从桶里拿一个令牌，拿到令牌才有资格执行调用请求。
③信号量
类是与漏斗，无论倒多少油，线面的漏管流量是有限的，如此限制流量。在应用层作为漏管来限制流量。
（4）失效转移模式
如果微服务架构中发生熔断和限流，如何处理被拒绝的请求：
①使用快速失败的策略，直接返回适用方错误，让使用方自行决定后续处理
②如果有备份服务，切换到备份服务处理
③服务提供者需要实现幂等性，采用重试的方式，失效的服务很可能是某台机器有问题（例如OOM问题），不是所有机器有问题。
7、微服务的粒度
拆分的粒度太细或者太粗都是不合理的。应该根据业务需求，能够满足上层服务对底层服务自由编排并获得更多的业务功能即可，并需要适合团队建设和布局