九周九分布式服务-架构演进

最新推荐文章于 2020-08-27 18:12:45 发布

畅聊架构

最新推荐文章于 2020-08-27 18:12:45 发布

阅读量394

点赞数

概述

随着业务的发展，项目的规模不断扩大，为了方便快速的构建迭代应用，应用的架构也在不断的演进，发展的核心问题是，服务化改造和服务治理。这种架构设计是，对复杂的应用进行水平拆分和服务化改造，将服务的消费者和服务的提供者解耦，增加复用性，减少公共模块的重复开发。系统可靠性和团队的协作能力也会有所提高。

应用架构的历史演进过程是这样的，下图展示了整个过程

架构演进

1. 垂直烟囱式架构：这类架构一般是一个war包搞定一切 [All in One]。

2. RPC架构：这类架构实现了前后端分离，这里不是指页面（html等）和后台代码（java等）的分离，是指逻辑上的前后端分离，前端逻辑和后端逻辑的分离，前端逻辑由Spring MVC框架完成，后端通过RPC框架完成业务逻辑接口的封装和暴露。

3. SOA架构：随着暴露接口的增多，在RPC架构中接口的管理和配置工作随之增加，这时对应用的架构提出了更高的要求，服务自动发现、自带负载均衡、服务自治、服务可编排等高级特性。这就是面向服务的架构设计（SOA）出现的历史原因。

4. 微服务架构：与SOA架构没有本质上的区别，是SOA架构进化出来的一种服务设计风格，特点是服务拆分粒度小、服务量大、真正实现敏捷交付、践行DevOps思想。

垂直架构

这种架构设计一般出现在业务发展初期，业务功能单一，业务量小。在垂直的架构中一般采用经典的MVC三层架构模型：

mvc架构模型

垂直的mvc三层架构，最前端的是视图展示层，是用户与之交互的界面；中间的控制层主要负责web请求的分发；第三层为应用模型层，这是业务逻辑的主要实现部分。

它的部署方式一般是如下形式：

垂直架构的部署方式

特点：

维护成本高，部署效率低，团队协作效率差，导致系统可靠性变差（在一个进程里面，一旦有一个接口出现故障，内存泄漏，会影响整个节点的宕机），新功能上线周期变长（耦合太多）。

RPC架构

RPC全称是Remote Procedure Call，是一种进程间通信方式，允许像调用本地服务一样的调用远程服务，一定程度上做到了公共服务的重用。支撑这种架构的框架就是RPC框架，业界流行的开源的RPC框架主要有：

1. FaceBook主导开发 Apache Thrift
2. Hadoop子项目 Avro-RPC
3. Caucho提供的Hessian
4. Google开源的gRPC（HTTP/2、protobuf）

在Java的语言环境中，实现原理中用的主要技术包括序列化、socket通信、动态代理、反射机制。其实徒手实现一个简单RPC框架也是不复杂的，主要是由三个部分组成：

服务提供者：运行在服务端，负责服务接口的定义和实现。
服务发布者：运行在RPC服务端，负责将本地服务发布成可远程调用的服务。
本地服务代理：运行RPC客户端，负责通过代理调用远程服务，将返回结果封装好供本地消费者使用。

RPC架构一般的部署方式：

RPC架构的部署方式

RPC框架的特点：简单、高效、通用，是SOA架构发展的底层技术支撑。

RPC架构的特点：一定程度上提高了服务的重用性，但是消费者调用服务提供者配置管理困难，并且消费者无负载均衡控制，调用关系梳理困难。

SOA架构

SOA是面向服务架构，是一种粗粒度的、以服务为中心的架构。业界流行的框架：

1. Dubbo/Dubbox（阿里/当当开源）
2. HSF（阿里商业版）
3. DSF（华为商业版）
4. Coral Service（亚马逊内部）
5. Spring Cloud（pivotal开源/商业版）

在上述框架中大家最熟悉的应该是Dubbo框架，Dubbo框架的官方文档写的非常好，学习分布式服务框架必读文档。

SOA架构的应用部署方式：

SOA架构的应用部署方式

与上面RPC架构的图相比，其中多了两个翅膀，不要小看这两个翅膀，它们为我们的服务开发和运维工作提供了很多便利，起到了为应用保驾护航的作用。

特点：

在服务注册中心的协助下实现了，服务自动发现、统一配置、可配置的服务路由、可配置的集群容错机制、服务治理等；服务治理也是依赖服务注册中心实现的，和具体的服务消费者和提供者是松耦合的，服务治理包括：服务运行态管控、服务生命周期管理、服务监控、服务安全、服务故障快速定位等功能；为运维工作提供了极大的便利。

微服务架构

微服务架构是一种服务化的架构风格，对服务的拆分粒度更细。微服务架构诞生肩负了更多的责任，最大限度的利用IT资源，容器化部署，敏捷交付以及自动化运维等。