微服务架构详解

单体架构vs微服务架构

单体架构：

定义：将所有的功能模块(service)打包到一起并放在一个web容器中运行。

单体架构图：

 

单体架构的优缺点

优点:

①: 架构简单明了。

②:开发，测试，部署简单。

缺点:

①：随着业务扩展，代码越来越复杂，代码质量参差不齐(开发人员的水平不一),会让你每次提交代码 ，修改每一个小bug都是心惊胆战的。

②: 部署慢(由于单体架构，功能复杂) 。

③: 扩展成本高。

④: 阻碍了新技术的发展。

微服务架构

定义：简单来说，微服务架构风格[1]是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

微服务架构图：

 

微服务架构的优缺点

优点:

①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点。

②: 开发简单，一个服务只干一个事情。

③: 微服务能够被2-5个人的小团队开发，提高效率。

④: 按需伸缩，服务松耦合，每个服务都能够开发部署。

⑤: 前后端分离, 作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参。

⑥:一个服务可用拥有自己的数据库，也可以多个服务连接同一个数据库。

缺点:

①:增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war包 。

②: 服务之间相互调用，增加通信成本。

③:数据一致性问题(分布式事务问题)。

④:性能监控等,问题定位。

微服务的适用场景

合适

①:大型复杂的项目(来自单体架构200W行代码的恐惧)。

②:快速迭代的项目(来自一天一版的恐惧)。

③:并发高的项目(考虑弹性伸缩扩容的恐惧)。

不合适

①：业务稳定，就是修修bug ，改改数据。

②：迭代周期长 发版频率 一二个月一次.。