最近在学习和总结微服务的反模式和陷阱:
学习和归纳如下：
微服务的目标:
1.单体应用的功能分隔成多个独立的、功能单一的服务
2.单体应用的数据分割成多个独立的小数据库
1、数据驱动的迁移反模式
背景: 服务的拆分，导致数据的迁移。如何避免频繁的数据迁移（反模式）
太多的数据迁移：随着服务的合并、拆分，数据频繁的迁移。
策略: 应该先功能分割优先，数据迁移最后。
2、超时反模式
在分布式架构中，管理服务的可用性和响应。设置超时时间是一个选择。超时时间一般根据：
1.数据库的超时时间
2.最长的负载计算时间
把这些值中的较大值*2，一般来说是超时时间的合理值。
但是为了判断服务是否可用，而等上x秒，是超时反模式。
策略：使用断路器。它会持续监控服务的可用性，可以在毫秒对服务的可用性给出判断。可以通过心跳检查或者用户实时检测的方式。
3、共享反模式
微服务是一直无共享的架构，或者称为不共享模式。总有些代码会在不同的服务间共享。如果太复杂的依赖，将导致依赖恶梦。这将导致版本控制和发布的噩梦。
常见的代码共享技术: 1.共享项目 2.共享库 3.复制
4.到达报告反模式
一般都是业务服务和查询服务数据库分库，查询（报表）服务的数据如何获取到最新的业务数据库呢? 主要有两方面的问题:
1.如何及时获得数据
2.如何保持数据和服务之间的界限
常见的方式有：
1.Database pull模式：服务依赖于数据库
2. HTTP pull 模式：慢
3. Batch pull 模式：查询（报表）服务依赖于数据库
4. Event-based push 模式：推荐。服务和数据之间隔离
5、沙粒陷阱
服务粒度至关重要，它会影响应用的性能、健壮性、可靠性、可测性、设置发布模型。
太粗的话: 性能好，但容易导致不容易测试和上线布署
太细的话: 容易上线部署、测速，但通信成本高，影响性能
如何确定服务的粒度呢？
5.1、分析服务的范围和功能：同一服务的CRUD可以归纳为一个微服务。不相关的可以拆出来
5.2、分析数据库事务：如果当你需要在 ACID vs. BASE 事务中做艰难的决定的时候，可能你的服务划分的就太细了。
5.3、分析服务编排：如果一个服务需要与很多服务打交道才能完成功能，说明服务粒度太小。
6、随大流陷阱
为什么选择微服务:
优点：
1.易部署
2.易测试
3.可扩展
缺点：
1.性能
2.可靠性
3.运维
7、REST陷阱
Rest是微服务的唯一选择吗? 很多时候需要考虑一下AMQP消息：
1.优势: 时延短
2.异步处理：削峰填谷
3.广播消息
4.事务消息
参考链接:
http://blog.csdn.net/u013970991/article/details/78079910
http://www.jianshu.com/p/c76f7f234a31
https://blog.csdn.net/u013970991/article/details/78092048
