微服务架构详解

一、微服务架构的由来

在微服务架构出现之前，最常用的架构就是单体架构，俗称"一个jar(war)包打天下"。在一个jar包工程中，采用MVC架构，分为表现层，业务层，数据访问层，所有的业务模块，都放在这个工程中集成，如下图所示:

随着软件行业规模的增长，这种单体架构的弊端也越来越多，包括:

1. 耦合性高，某个地方出问题，很可能影响其他业务模块的使用
2. 代码管理成本高，项目沉重，并会随着需求的增加越来越重
3. 随着访问量的增多，这种架构的工程并发力不够
   … …

为了解决单体结构带来的问题，就出现了微服务架构。

微服务架构就是将单一程序拆分成一个一个的微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL

API。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。

二、微服务架构优势与劣势

优势：

复杂的业务拆分成多个业务，每个业务是一个独立的微服务，彻底的去耦合，利于分工，当需要增加业务的时候，可以方便创建新的微服务扩展业务，而不用担心有没有别的地方耦合

每个微服务都是独立部署的，如果其中一个宕机了，不会影响整个系统ÿ