什么是微服务架构呢？简单说就是将一个完整的应用（单体应用）按照一定的拆分规则（后文讲述）拆分成多个不同的服务，每个服务都能独立地进行开发、部署、扩展。服务于服务之间通过注入RESTful api或其他方式调用

微服务的目的在于有效的拆分应用,  以实现敏捷开发和部署

微服务的不足

1、多服务部署运维难度

2、服务间通信成本

3、数据一致性

4、系统集成测试

5、性能监控

好处：

1、功能特定,  一个微服务完成 一个特定的功能

2、复杂度可控,  将应用合理分解,避免复杂度无止境的积累

3、可以进行独立部署, 降低生产环境部署时对整个系统的运营风险

4、容错, 当一组应用发生错误时,在合理的设计下, 其不会影响其他应用的使用

5、扩展,  单块应用也可以实现横向扩展,  可以根据应用需求独立进行扩展

拆分原则：

　　 不好的实践

• 以代码量作为衡量标准，例如500行以内。
• 拆分的粒度越小越好，例如以单个资源的操作粒度为划分原则。

　　 建议的原则

• 功能完整性、职责单一性。
• 粒度适中，团队可接受。
• 迭代演进，非一蹴而就。
• API的版本兼容性优先考虑。

　　代码量多少不能作为衡量微服务划分是否合理的原则，因为我们知道同样一个服务，功能本身的复杂性不同，代码量也不同。还有一点需要重点强调，在项目刚开始的时候，不要期望微服务的划分一蹴而就。

　　微服务架构的演进，应该是一个 循序渐进的过程。在一个公司、一个项目组，它也需要一个循序渐进的演进过程。一开始划不好，没有关系。当演进到一个阶段时，微服务的部署、测试和运维等成本都非常低的时候，这对于你的团队来说就是一个好的微服务。

　　微服务架构的开发原则

　　微服务的开发还会面临依赖滞后的问题。例如：A要做一个身份证号码校验，依赖服务提供者B。由于B把身份证号码校验服务的开发优先级排的比较低，无法满足A的交付时间点。A会面临要么等待，要么自己实现一个身份证号码校验功能。

　　以前单体架构的时候，大家需要什么，往往喜欢自己写什么，这其实是没有太严重的依赖问题。但是到了微服务时代， 微服务是一个团队或者一个小组提供的，这个时候一定没有办法在某一个时刻同时把所有的服务都提供出来，“需求实现滞后”是必然存在的。

　　一个好的实践策略就是 接口先行，语言中立，服务提供者和消费者解耦，并行开发，提升产能。无论有多少个服务，首先需要把接口识别和定义出来，然后双方基于接口进行契约驱动开发，利用Mock服务提供者和消费者，互相解耦，并行开发，实现依赖解耦。

　　采用契约驱动开发，如果需求不稳定或者经常变化，就会面临一个接口契约频繁变更的问题。对于服务提供者，不能因为担心接口变更而迟迟不对外提供接口，对于消费者要拥抱变更，而不是抱怨和抵触。要解决这个问题，一种比较好的实践就是 管理 + 技术双管齐下：

• 允许接口变更，但是对变更的频度要做严格管控。
• 提供全在线的API文档服务（例如Swagger UI），将离线的API文档转成全在线、互动式的API文档服务。
• API变更的主动通知机制，要让所有消费该API的消费者能够及时感知到API的变更。
• 契约驱动测试，用于对兼容性做回归测试。

服务化架构演进历史

微服务（Microservice）那点事

http://www.importnew.com/17588.html

深度剖析微服务架构的九大特征

http://developer.51cto.com/art/201608/516401.htm

微服务拆分实践

http://www.jianshu.com/p/80832f2d7a35