微服务的六种设计模式
1. 聚合模式
把一个大的服务拆分成多个原子服务，同时也将拆分数据库。这就会带来跨库的事务完整性、跨库的关联查询。这是微服务避不开的问题。解决，不拆分数据库。但随着业务增加，可能拆分数据库是必需的了。
跨库的关联查询解决方案
问题：性能和权限
比如订单、客户、供应商方案中。
解决1：定单，只查订单库，返加给前端部分结果，前端再根据返回的结果调用客户、供应商服务得到关联信息。
通过内存缓存存储相关数据。
通过数据冗余提高查询性能。（定单中保存部分用户、供应商信息。如果用户变化等，定单表是需要需要跟着变，根据业务情况来确定；查询是较多的业务量，更新是较少的业务量，采用这种方案也是较优的）
补填，例子，https://github.com/mooodo/demo-service2-product
分布式事务：两阶段提交
第一阶段： 分别验证事务是否可能成功
第二阶段： 真正提交
第一阶段只操作不提交，会锁定表，严重影响系统性能，
如果第一阶段提交，当出错时，进行事务补偿。
分布式事务：TCC方案
实现三个接口。
T: Try 检验各方事务是否可以作，做准备工作
C: confirm 真正做操作。
C: Cancel 事务补偿，confirm的反向操作
分布式事务：基于消息的最终一致方案
分布式事务：单体应用的服务转型
把公共的部分提出，作成微服务。
把复杂的业务折出，做成微服务。
逐渐形成聚合型。
能不折，就不折。该折才折。每个微服务模块中的代码即不太多，也不大太少。
2. 代理模式
与聚合区别，If 条件1 ，调ServiceA；If 条件2， 调用Service2 ...
如果调用A服务，因业务变化，老用户调用 A，新用户调用B。使用代理服务，注册成A的名字，A改成新的名字。应用的改动很小。
3. 链式模式
链式模式使用范围很小，很多情况下被聚合服务代替了。
4. 分枝模式
聚合服务与代理服务组合，形成分枝模式
也可能是聚合与聚合服务组合。
5. 异步模式
服务间通过异步方式。服务B调用服务C，如果C很慢，就不能使用同步方式，通过异步模式解决高并发、高吞吐量的问题。
6. 数据共享模式
有观点：微服务初期的临时状态。
当微服务与大数据结合时，都必然这数据共享模式。
对数据库拆分后，解决写的问题，但各种复杂查询性能会下降。
读写分离
近期热数据放到数据库集群中，对大量的历史数据放到大数据平台上。
实时性高的查询到到数据库中，大数据平台解决非实时性高的查询。
大数据平台上优化查询，方法：建立宽表，宽表与join结合（比如代码表，数据量较小的表）
微服务的无状态设计
session的复制；如是要节点增长，Session复制成本增长很快，n*(n-1)/2
session绑定；如果节点Down，此会出问题
session存储到Redis中；各节点共享Redis
设计原则
微服务无状态设计，把Session、值对像传递、状态数据存储在共享存储中
sessionId/token存储到Redis。Http请求中，将此值存储到Http Header中。
微服务架构设计的反模式
- 太多的数据迁移
功能拆分优先，数据迁移最后 - 数据共享反模式
容易设计不到位。数据库一表只能一个微服务访问。 - 频繁交互反模式
拆分太细了。
