写于:2019-03-12 21:52:37

随着时代的发展,在互联网浪潮的推动下我们的生活正在发生变化。软件架构也不例外。

下图是一个简单的架构变迁历程 分布式架构变迁

不过不管架构如何变,其本质都是在落实 "分而治之" 这一理念。

谈到分布式架构,就不得不说目前火热的微服务架构以及新兴的服务网格架构。而这些架构出现也不是横空出世,是一点点累积的过程,一切变革都是必然的。 对比传统行业应用,互联网应用需要面对海量的数据,更高业务复杂度,更高并发访问,传统的服务架构明显无法支撑这一需求,而架构的转变也自然而然的发生。

下面我们来谈谈,从早期到现在架构的演进。

# JEE/SSH/SSM

JEE/SSH/SSM

在早期的系统开发中,服务开发采用的是分层架构的模式,也就是 MVC 模式。针对控制端的UI 界面处理,业务逻辑处理以及数据库操作进行三层的一个架构划分。这样的架构划分,对于早期的架构开发来说,已经足够。

MVC 划分针对是逻辑上的划分,而非物理上的划分,应用在部署时,将所有内容打成一个包运行在web容器中,运行在同一个JVM中,运行在同一个进程中。该架构就是 All in one 的一种架构。

随着互联网时代的到来,互联网带来的高并发,复杂的业务场景中,采用该架构的应用越来越臃肿,业务代码耦合度增强,代码变得难以维护,服务性能受到明显影响产生瓶颈。

于是架构的开始转变。

# SOA-Web Service/ SOA-ESB

在互联网软件架构中针对JEE/SSH/SSM 单一应用部署存在的瓶颈问题提出了解决方案 SOA (Service-Oriented Architecture) -服务化架构。

# Web Service

JEE/SSH/SSM

SOA 架构通过将业务功能进行拆分,拆分成不同的服务,不同的服务进行各自的部署。这样解决了单一应用开发造成的业务越来越复杂,耦合越来越高开发难维护难的问题。针对不同服务各自进行部署同时解决了单一应用性能问题,并且可以针对不同服务功能进行不同的服务配置,提高资源利用率。

不过web service 也存在问题,web service 服务间通信是通过向 web service 目录 注册,获取服务列表完成的,这使得 web service 目录成为系统高可用的一个瓶颈,同时webservice 在服务间通信采用的 SOAP协议,而 SOAP 协议结构复杂,数据量大,造成的网络开销大,导致系统响应慢等问题的存在。

# ESB

JEE/SSH/SSM

ESB 架构模式是 Web Servicer 的变种,其不同于 Web Service 之处在于其增加一条总线。而这条总线能够干嘛用,它主要是用来规范服务通信的,如果ServiceA 使用的JAVA开发的,ServiceB 使用的是 C++ 开发,Service B 属于其他的业务模块要打通其于Service A 的通信,这时候需要面对就是更这两个服务采用的需要是同一个协议规范。而这条总线干的就是将不同标准的协议格式进行统一转化,然后进行服务间的通信,这样减少了针对两个服务的侵入性系统修改,实现可插拔的模式。下一次来一个新的服务应用,就插上去,不要了就拔掉,针对于不同语言编写的服务实现可插拔式,无侵入的优势。

# 微服务

JEE/SSH/SSM

微服务是最近比较火热的一个架构模式,微服务汲取了SOA 的架构设计思想演变的一种新的架构模式。 微服务在架构中,不同于 SOA 的服务化,微服务直接将某一个功能独立成一个服务应用,支持独立部署、独立开发、独立数据库,在不考虑业务场景的情况下,能能够独立部署,独立运行。 服务间通过协议,如:http 协议进行通信协议。使得整个应用在开发中能够快速开发,敏捷上线。不过其存在的问题也很明显,如:不同功能模块如果由不同开发组进行分别开发,沟通成本会增加。在应用开发中也同样会存在很多问题,如分布式事务,数据一致性等问题。

# Service mesh

JEE/SSH/SSM

在互联网时代以及未来IOT 时代高速发展下,除了应时代而生的微服务架构,最近悄然而起的 Service Mesh 逐渐进入到我们眼中。 Service Mesh 在服务化应用变得越来越受欢迎。

为什么 Service Mesh 会成为继 微服务之后的又一个户关注的服务化架构。

谈到服务化,不得不谈的就是服务间通信,而服务间通信包括,服务发现,路由,监控,安全、日志、API网关等。

而其中 API 网关是整个系统的中转站,其承担了通信路由,服务熔断,超时管理等控制。因此 API 网关也会变得越来越臃肿。且由于 API网关的重要性其会成为系统的一个瓶颈。 这时候就得谈谈 Service Mesh 了。Service Mesh 是网络通信基础设施,可能将网络功能从 代码中剥离出来,通过Service Mesh 可以不用在代码中实现可靠的通信模式和断路器等控制,直接使用 service Mesh 用于控制和监控并提供服务应用程序中服务到服务的快速、安全、可靠的内部通信。

我们可以将Service Mesh看成路由器和交换机互联的设备组成的(第七层)网络。 其原理就是由代理 proxy 附属于某一应用程序,为该应用程序提供如路由,负载均衡,监控,通信等功能。并且该功能对应用代码无侵入。

# CAP/BASE

谈到分布式,就不得不提 CAP 原理和 BASE 思想。

# CAP

JEE/SSH/SSM

Consistency:一致性 Availabillity:可用性 Partition tolerance:分区容错性

所谓的分布式架构就是将原本单一的应用,拆分多个应用,然后多个应用通过特定的协议进行通信。 在服务应用通信过程中,网络出现故障导致两个应用服务无法正常通信,这时候两个应用需要分别进行服务提供,这就是 CAP 中的 "P" 分区容错性。当我们确定了 "P" 为必然存在的条件,之后我们应该如何选择 "A" 和 "C"。换句话就是:在一个允许网络发生故障的系统中,该选择一致性还是可用性?

有的人会说:小孩子才做选择,我全部都要!

不过这边确实没办法都要!下面我们来举个栗子。 首先我们确定了 "P" 为必要条件。如图

JEE/SSH/SSM

在该环境中存在2个数据存储服务,其中 Server 1 和Server2是主从关系。 在某一时刻,Server 1收到了写请求,不过再同步到Server2的时候出现了网络故障,这时候Server1 和 Server2的数据是不一致的。 这时候有两种选择: 选"A",可用性:也就是说Server1 和 Server2 仍然向外提供服务,但是这时候两台服务中的数据是不一致的。所以选择了可用性,就无法提供一致性。

选“C”,一致性:也就是说 Server1 和 Server2 需要等到网络恢复正常,两台服务中的数据一致之后,才对外提供服务。所以选择了一致性,就无法提供可用性。

那难道没有解决办法?

有,那就是 BASE 理论的提出

# BASE

BA:Basically Avaliable ->基本可用 S:Soft state 软状态,状态可以有一段时间不同步。 Eventually consistent 最终一致性。

通过看 Base 理论的定义就能够得出 上面 CAP 的解决方案,那就是放弃强一致性,采用最终一致性的方案来解决。

精彩内容推送,请关注公众号!
最近更新时间: 3/24/2020, 9:44:42 PM