微服务

Technorati 标签: 微服务

本文根据什么是微服务改编而得。

单体架构的问题

下图是一个单体架构的系统。

所有的业务子模块都集成在一个很重的JVM进程中。好处在于便于管理，所有的代码都在同一个项目中，但是当产品规模变大了以后，问题也来了。

• 项目过于臃肿：
• 资源无法隔离：所有功能模块都依赖于同样的数据库、内存等资源，有可能因为一个功能模块对资源使用不当，而造成整个系统的崩溃。
• 无法灵活扩展：
  当系统访问量了以后，单体系统只能进行水平扩展，也就是部署在多台机器上组成集群。但是不够灵活，比如现在的性能瓶颈是支付模块，如果要只针对支付做水平扩展，这一点在单体系统上做不到。

那么可以把臃肿的系统拆分为微服务

微服务

所谓微服务，就是将单个功能模块做为一套小型服务进行开发，可以通过自动化部署独立部署。

那么微服务有什么特点呢？

• 独立部署，灵活扩展：传统的单体架构是以整个系统为单位进行部署，而微服务是以每一个独立的组件为单位进行部署。

比如根据每个服务的吞吐量不同，部署不同数量的主机，比如支付部署20台主机，用户服务部署30台。这种灵活的部署方式，只有微服务可以做到。

而现在流行的Docker，为微服务架构提供了有效的容器

• 资源的有效隔离：
  微服务的设计原则之一就是每个微服务拥有独立来数据源，如果微服务A要读写微服务B的数据库，需要调用微服务B对外的接口来完成，有效的避免了服务处之间争用数据库和缓存资源带来的问题。
  
  同时，每个微服务实例在Docker容器上运行，实现了服务器资源的有效隔离

微服务的不足

• 把原来的项目拆分成多个独立工程，增加了开发和测试的难度。
• 拆分以后，就需要保证不同服务之间的数据一致性，所以引入了分布式事务和异步补偿机制，使得设计更复杂。
  

微服务与面向服务架构SOA的区别

微服务听起来和SOA面向服务架构听起来差不多，那么他们有什么区别呢？

SOA架构是一种粗粒度、松耦合的服务架构，更多的是强调异构系统之间的服务通信。

比如这样子：

总之，

• SOA架构强调的是异构系统之间的通信和解耦合，
• 而微服务架构强调的是系统按业务边界做细粒度的拆分和部署。