微服务架构之路 原理解析

随着业务发展，应用规模扩大，系统的一些公共服务就会抽取出来，独立开发，部署，维护，用来解决并发，扩展，维护的问题

单一（集中式）应用架构

一个归档包（例如war格式或者Jar格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构

最开始是这种传统的应用架构，针对公司业务来说，体量没那么大，成本低，部署方便。也不需要考虑高并发大流量可扩展性什么的，简单粗暴，解决业务需求就好，活下去才能活的更好。
优点
项目架构简单，前期开发成本低，周期短，小型项目的首选
缺点

• 模块之间耦合度太高,其中一个功能升级,其他的模块都得一起升级部署。
• 开发困难,各个团队开发最后都要整合在一起.
• 系统扩展性差
• 不能灵活进行分布式部署

垂直应用架构

我理解垂直结构指的就是分层，就是将一个业务拆分为几部分，而不是一条线下来。

用户访问量越来越大，机器承的响应速度跟不上，这个垂直应用架构就可以体现价值了。但是应用之间耦合度高，相互依赖严重
优点：

• 在一定程度上解耦
• 性能相比有提升，扩展性更快

缺点

• 随着这种小的模块越来越多，模块之间的调用关系会越来越复杂，不便于维护和管理
• 远程过程调用会使得代码量会急剧增加
• 各个开发团队各自为战，开发效率低下
• 测试工作量巨大，发布困难

微服务架构

为了解决前面架构存在的问题，微服务应用突出的特点在于服务治理，每个服务独立部署运行。下面是执行方案

1. 核心业务抽取出来，作为独立的服务对外服务
2. 服务模块持续独立部署，减少版本交付周期
3. 数据库按服务分库分表。大量使用缓存，提高访问
4. 系统间交互使用轻量级的 rest 协议，摒弃 rpc 协议

上面的图针对ngix的负载均衡以及数据库的主从分库就没有体现了，自行get。

优点：

• 结构清晰，职责单一，高内聚
• 业务复用高
• 产品迭代周期更短