Technorati 标签: 微服务
本文根据什么是微服务改编而得。
单体架构的问题
下图是一个单体架构的系统。
所有的业务子模块都集成在一个很重的JVM进程中。好处在于便于管理，所有的代码都在同一个项目中，但是当产品规模变大了以后，问题也来了。
- 项目过于臃肿：
- 资源无法隔离：所有功能模块都依赖于同样的数据库、内存等资源，有可能因为一个功能模块对资源使用不当，而造成整个系统的崩溃。
- 无法灵活扩展：
当系统访问量了以后，单体系统只能进行水平扩展，也就是部署在多台机器上组成集群。但是不够灵活，比如现在的性能瓶颈是支付模块，如果要只针对支付做水平扩展，这一点在单体系统上做不到。
那么可以把臃肿的系统拆分为微服务
微服务
所谓微服务，就是将单个功能模块做为一套小型服务进行开发，可以通过自动化部署独立部署。
那么微服务有什么特点呢？
- 独立部署，灵活扩展：传统的单体架构是以整个系统为单位进行部署，而微服务是以每一个独立的组件为单位进行部署。
比如根据每个服务的吞吐量不同，部署不同数量的主机，比如支付部署20台主机，用户服务部署30台。这种灵活的部署方式，只有微服务可以做到。
而现在流行的Docker，为微服务架构提供了有效的容器
- 资源的有效隔离：
微服务的设计原则之一就是每个微服务拥有独立来数据源，如果微服务A要读写微服务B的数据库，需要调用微服务B对外的接口来完成，有效的避免了服务处之间争用数据库和缓存资源带来的问题。
同时，每个微服务实例在Docker容器上运行，实现了服务器资源的有效隔离
微服务的不足
- 把原来的项目拆分成多个独立工程，增加了开发和测试的难度。
- 拆分以后，就需要保证不同服务之间的数据一致性，所以引入了分布式事务和异步补偿机制，使得设计更复杂。
微服务与面向服务架构SOA的区别
微服务听起来和SOA面向服务架构听起来差不多，那么他们有什么区别呢？
SOA架构是一种粗粒度、松耦合的服务架构，更多的是强调异构系统之间的服务通信。
比如这样子：
总之，
- SOA架构强调的是异构系统之间的通信和解耦合，
- 而微服务架构强调的是系统按业务边界做细粒度的拆分和部署。
