文章目录
part1_系统架构演变
随着互联网的发展,网站应用的规模不断扩大。需求的激增,带来的是技术上的压力。系统架构也因此不断的演进、升级、迭代。从单一应用,到垂直拆分,到分布式服务,到SOA,以及现在火热的微服务架构,还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方,还是偏安一隅得过且过?
原始集中式架构
当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。举个例子,一个应用的各项功能全部部署在一个Tomcat中。
存在的问题:
- 单点故障,假设该服务器崩溃、整个应用将瘫痪
- 并发很低。
- 代码耦合度过高,不同服务全在一个工程中互相调用、难以进行独立优化。(你不知道你做的优化是否会影响调用这个功能的某个模块)
- 针对并发高的服务无法进行水平扩展。
优点:
- 维护之间,出现问题只需要复盘部署该应用的服务器(如Tomcat)
用户到数据库之间只有一条通道。
垂直拆分
针对原始架构进行了解耦。当访问量逐渐增大,单一应用无法满足需求,此时为了应对更高的并发和业务需求,我们根据业务功能对系统进行拆分,每个业务功能单独作为一个应用。
优点:
- 系统拆分实现了流量分担,解决了并发问题
- 可以针对不同模块进行优化
- 方便水平扩展,可针对特定模块进行负载均衡或集群部署,容错率提高
缺点:
- **系统间相互独立,无相互调用、**会有很多重复开发工作,影响开发效率;存在大量代码冗余。
- 增加维护成本。
分布式服务
当垂直应用越来越多,应用之间交互不可避免,分布式架构将服务分为基础服务和业务功能(也是一种服务)、基础服务具有和数据库交互的权限、且可以被不同的业务功能业务进行调用。此时、服务之间的调用是关键
优点:
- 解决了垂直拆分下代码冗余的问题,将基础服务进行了抽取,系统间相互调用,提高了代码复用和开发效率
缺点:
- 系统间耦合度又变高了,调用关系错综复杂,难以维护
面向服务架构(SOA)
SOA解决的传统分布式不同服务之间调用关系错综复杂的缺陷、同时也解决的垂直拆分的服务之间独立的代码冗余问题。
以Dubbo框架的架构为例