单体架构

传统的项目都是MVC架构，所有业务子模块都集成在一个很重的JVM中。

这种的单体架构的好处是便于管理，所有的代码都在一个项目中。
当产品的规模越来越大，其坏处也很明显。

• 缺点一：项目过于臃肿当大大小小的功能模块都集成在同一个项目的时候，整个项目必然会变得臃肿，让开发者难以维持。
• 缺点二：资源无法隔离，整个单体系统的各个功能模块都依赖于同样的数据库，内存等资源，一旦某个功能模块对资源使用不当，整个系统就会垮掉。
• 缺点三：无法灵活扩展 当系统的访问量越来越大的时候，单体系统固体可以水平扩展，部署到集群上，这种扩展并灵活的扩展。这一点单体系统是做不到的

如何解决

把臃肿的单体系统拆分成【微服务】

什么是微服务

微服务（Microservice Architecture）是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。

究竟什么是微服务呢？我们在此引用 ThoughtWorks 公司的首席科学家 Martin Fowler 的一段话：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services,
each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
These services are built around business capabilities and independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

特点

• 独立部署，灵活扩展 传统的单体架构是以整个系统为单位进行部署的，而微服务则是以
  每一个独立组件（例如用户服务，商品服务）为单位进行部署的。

用一张经典的图来表现，就是下面这个样子：

图中左边是单体架构的集群，右边是微服务集群。

什么意思呢？比如根据每个服务的吞吐量不同，支付服务需要部署20台机器，用户服务需要部署30台机器，而商品服务只需要部署10台机器。这种灵活部署只有微服务架构才能实现。

• 资源的有效隔离。微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。
  这样有效避免了服务之间争用数据库和缓存资源所带来的问题。

  同时，由于每一个微服务实例在Docker容器上运行，实现了服务器资源（内存、CPU资源等）的有效隔离。

• 团队组织架构的调整微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。

  而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。

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

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

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

• 可以说Dubbo和Sprig Cloud 很好的支持了SOA和微服务架构，但不能说Dubbo 是SOA，SPring Cloud是微服务。

微服务的不足

• 微服务吧原有的系统项目拆成了很多独立工程，增加了开发和测试的复杂度。
• 添加小功能是比较复杂。
• 微服务架构需要保证不同服务之间的数据一直性，引入了分布式事务和异步补偿机制，而为设计和开发带来了一定的挑战。
• 微服务没有绝对的好坏，关键也是需要看应用场景的。