SpringCloud_从分布式到微服务的架构演变

part1_系统架构演变

随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方，还是偏安一隅得过且过？

原始集中式架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。举个例子，一个应用的各项功能全部部署在一个Tomcat中。

存在的问题：

• 单点故障，假设该服务器崩溃、整个应用将瘫痪
• 并发很低。
• 代码耦合度过高，不同服务全在一个工程中互相调用、难以进行独立优化。（你不知道你做的优化是否会影响调用这个功能的某个模块）
• 针对并发高的服务无法进行水平扩展。

优点：

• 维护之间，出现问题只需要复盘部署该应用的服务器（如Tomcat）

用户到数据库之间只有一条通道。

垂直拆分

针对原始架构进行了解耦。当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分，每个业务功能单独作为一个应用。

优点：

• 系统拆分实现了流量分担，解决了并发问题
• 可以针对不同模块进行优化
• 方便水平扩展，可针对特定模块进行负载均衡或集群部署，容错率提高

缺点：

• **系统间相互独立，无相互调用、**会有很多重复开发工作，影响开发效率；存在大量代码冗余。
• 增加维护成本。

分布式服务

当垂直应用越来越多，应用之间交互不可避免，分布式架构将服务分为基础服务和业务功能（也是一种服务）、基础服务具有和数据库交互的权限、且可以被不同的业务功能业务进行调用。此时、服务之间的调用是关键

优点：

• 解决了垂直拆分下代码冗余的问题，将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

• 系统间耦合度又变高了，调用关系错综复杂，难以维护

面向服务架构（SOA）

SOA解决的传统分布式不同服务之间调用关系错综复杂的缺陷、同时也解决的垂直拆分的服务之间独立的代码冗余问题。

以Dubbo框架的架构为例