一、单体架构

1.1 介绍

  • 单体架构在历史进程里,出现时间最早,应用范围最广、使用人数最多、统治历史最长。
  • 单体 这个词是从微服务开始流行后,“事后追认”的一种架构。
  • 很多微服务的介绍中,将其称之为 **巨石系统 (Monolithic Application) **

1.2 优点

  1. 易于开发调试、测试、部署、开发。
  2. 运行效率比分布式系统药膏
  3. 架构简单,开发快成本低

1.3 缺点

  1. 项目模块耦合严重,维护和沟通成本会更高,无法对某类高峰业务单独进行拓展,只能针对整体进行拓展。
  2. 核心业务和边缘业务互相影响,导致系统可靠性不足。
  3. 到了后期系统工程愈发庞大后,新增功能会非常复杂,同时不利于开发、运维。工程混乱

1.4 总结

单体并不就代表落后的系统架构风格,单体作为一个小型系统,不需要进程间通信易于部署、易于测试、开发、部署、调试。且效率比分布式系统更高。适合需求少、并发小,要求快速开发交付的项目初期发展阶段。未来会长期存在。

二、垂直架构

2.1 介绍

  1. 垂直架构一般是因为单体架构太过于庞大而进行的拆分,拆分后各个系统应满足独立运行互相不影响
  2. 也有可能时某个平台招标由不同厂商负责不同子系统的开发
  3. 垂直架构可以看成是多个单体架构的组合

2.2 优点:

  1. 对比单个单体架构系统,它拆分了系统的流量,可以针对高峰共功能进行拓展
  2. 优化了单体架构过于庞大时出现的难以维护的问题。

2.3 缺点:

  1. 在各个系统间单体架构存在的问题仍然存在并且有新的问题产生
  2. 会有功能的重叠,重复造轮子
  3. 拆分后存在隔离与治理能力上的欠缺,并且会给技术异构带来麻烦。
  4. 拆分后可能带来数据冗余,但是又需要进行同步,要么使用数据库层面的同步,要么使用系统间的接口进行同步处理。
  5. 系统之间的交互,由于缺少隔离与治理能力,一般都是硬编码的点对点交互。

三、分布式架构

  • 分布式架构 简单来说就是一组计算机组成一个系统的整体,一致对外提供服务
  • 这组计算机内的不同系统,都可以互相通信
  • 客户端到服务端的一次请求响应,可能会历经多台计算机。

四、分布式架构-SOA

IBM对SOA的介绍:https://www.ibm.com/cn-zh/topics/soa

4.1 SOA架构的历史

  1. SOA最早时由Gartner公司,1994年提出但当时没有发展条件。
  2. 2006年 IBM、Oracle、SAP等公司,成立了OSOA联盟,来指定SOA的相关行业标准
  3. 2007年 结构化咨询标准促进组织 OASIS 的倡议和支持下,OSOA联合OASIS成立了 Open CSA组织,也就是SOA的官方管理机构。
  4. 到SOA时代,许多概念都能在微服务中找到对应的身影了。例如服务之间的松耦合、注册、发现、治理、隔离、编排等等。

4.2 介绍

  1. SOA有自己的技术标准组织,OPEN CSA、有清晰的设计指导原则比如服务的封装性、自治、松耦合、可重用、可组合、无状态,等等.
  2. SOA 架构明确了采用 SOAP 作为远程调用的协议,依靠 SOAP(简单对象访问协议) 协议族(WSDL、UDDI 和一大票 WS-* 协议)来完成服务的发布、发现和治理;
  3. Web Service 广义来说是服务网络化基于WEB传输的能力。但是一般指 基于SOAP协议实现的远程服务调用模型。
  4. SOA 架构会利用一个被称为是企业服务总线(Enterprise Service Bus,ESB)的消息管道,来实现各个子系统之间的通讯交互,这就让各个服务间在 ESB 的调度下,不需要相互依赖就可以实现相互通讯,既带来了服务松耦合的好处,也为以后可以进一步实现业务流程编排(Business Process Management,BPM)提供了基础;
  5. SOA 架构使用了服务数据对象(Service Data Object,SDO)来访问和表示数据,使用服务组件架构(Service Component Architecture,SCA)来定义服务封装的形式和服务运行的容器;

4.3 优点

  1. 对公共服务进行拆分,避免了重复造轮子问题。抽离出的服务使用ESb企业总线来进行规范的同意信息交互,避比原来点对点的交互模式耦合度更低。
  2. 对比垂直架构,SOA对业务的拆分更清晰、职责更单一拓展性更强。
  3. 不强行打通数据库层面壁垒,让数据回到隔离状态,信息孤岛由接口解决。
  4. 系统架构有详实的标准。

4.4 缺点

  1. 通过ESB中转带来的性能损耗,所有交互通过ESB进行,ESB宕机后所有系统都会受到牵连。
  2. 公共服务抽取后,业务系统和服务之间高度耦合。
  3. 复杂度太高,不利于一般的开发

4.5 总结

SOA 架构过于严谨精密的流程与理论,导致了软件开发的全过程,都需要有懂得复杂概念的专业人员才能够驾驭。从 SOA 诞生的那一天起,就已经注定了它只能是少数系统的阳春白雪式的精致奢侈品:它可以实现多个异构大型系统之间的复杂集成交互,却很难作为一种具有广泛普适性的软件架构风格来推广。Web Service被边缘化的本质,也是因为过于严格的规范定义,带来了过度的复杂性。

五、微服务架构

一句话介绍微服务
微服务是一种通过多个小型服务的组合,来构建单个应用的架构风格,这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程之中。服务会采取轻量级的通讯机制和自动化的部署机制,来实现通讯与运维。

康威定律:设计系统的架构受制于产生这些设计的组织的沟通结构

5.1 历史

  1. Peter Rodgers 博士在 2005 年的云计算博览会(Web Services Edge 2005)上,就已经提出和使用,指的是一种专注于单一职责的、与语言无关的、细粒度的 Web 服务(Granular Web Services)。
  2. 早期的微服务被认为是SOA的一种轻量化补救方案
  3. 2021年 Thoughtworks 首席咨询师 James Lewis 的演讲 《Microservices – Java, the Unix Way》 号召大家重拾Unix的设计哲学
  4. 2014年 微服务崛起,Martin Fowler 和 James Lewis 合写的文章“Microservices: a definition of this new architectural term”让人们真正了解到微服务。

5.2 微服务的核心业务与技术特征

  1. 围绕业务能力构建 Organized around Business Capabilities
  2. 分散治理(Decentralized Governance) 表达的是“谁家孩子谁来管”。微服务不反对也不提倡技术上的统一,只要能维护号自己的服务。
  3. 通过服务来实现独立自治的组件(Componentization via Services)
  4. 产品化思维(Products not Projects)避免把软件研发看作是要去完成某种功能,而要把它当做是一种持续改进、提升的过程
  5. 数据去中心化(Decentralized Data Management)数据应该按领域来分散管理、更新、维护和存储。虽然更容易导致一致性的问题,但是为了独立性有些代价是必须要付出的。
  6. 轻量级通讯机制(Smart Endpoints and Dumb Pipes)反对ESB、BPM和SOAP等复杂的通信机制。微服务体长类似于Unix一样简单直接地通信方式,RESTful风格的通信在微服务中就很合适。
  7. 容错性设计(Design for Failure) 不再追求服务永远稳定不出错,而是接受服务总会出错的现实。可靠的系统完全可以由会出错的服务来组成。容错性设计要求:
    1. 有自动的机制能快速检测故障
    2. 持续出错时,能对出错的服务进行隔离,服务恢复时自动联通(所以熔断器在微服务环境中时必须的) 没有这一项容易导致系统雪崩
  8. 演进式设计(Evolutionary Design) 容错性设计承认服务会出错,而演进式设计则是承认服务会被报废淘汰。一个良好的设计服务应该是能够报废的,否则一个服务不可替代,则说明这是系统设计的脆弱。微服务带来的独立、自治就是再反对这种脆弱。
  9. 第九,基础设施自动化(Infrastructure Automation) 基础设施的自动化,例如CI/CD的发展,大大降低了构建、发布、运维工作的复杂性。

自由的架构风格

  1. 微服务没有统一的约束和规定,提倡以”实践标准” 代替 ” 规范标准”
  2. 服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩拓展、传输通讯、事务处理等问题。在微服务中不再会有统一的解决方案。
  3. 例如在 Java 范围内的微服务通讯问题,可以选区的方案就很多:RMI(Sun/Oracle)、Thrift(Facebook)、Dubbo(阿里巴巴)、gRPC(Google)、Motan2(新浪)、Finagle(Twitter)、brpc(百度)、Arvo(Hadoop)、JSON-RPC、REST,等等。
  4. 服务发现的解决方案:Eureka(Netflix)、Consul(HashiCorp)、Nacos(阿里巴巴)、ZooKeeper(Apache)、etcd(CoreOS)、CoreDNS(CNCF),等等。

5.3 总结

优点:

  1. 已于开发和维护,服务拆分的足够细
  2. 启动速度快、不限制技术栈、局部修改容易

缺点:

  1. 分布式固有的复杂性 容错、延迟、事务 等都是必须考虑的。
  2. 接口调整成本高
  3. 服务公用的功能需要内聚,可能会重复。
  4. 服务更多的话,运维就会更复杂

总结

  1. 微服务中,不需要背上SOA的包袱,需要解决什么问题就引入什么工具,团队熟悉什么技术就是用什么框架
  2. 类似Spring Cloud的胶水式全家桶,通过一致的接口、声明、配置 进一步屏蔽了源自具体工具、框架的复杂性。也降低了不同工具、框架的切换成本。对于开发者来说,微服务架构是友善的。

六、目前分布式架构的通信方式

因为传统的单体架构,服务都部署在一个主机上所以不涉及远程服务调用,但是对分布式系统来说,服务间的调用就是实现分布式的关键因素

6.1 直接使用HTTP协议进行服务间通信

HttpURLConnection
java 原生 HttpURLConnection是基于http协议的,支持get,post,put,delete等各种请求方式,最常用的就是get和post
Apache Common HttpClient
HttpClient 是Apache Common 下的子项目,可以用来提供高效的、最新的、功能丰富的支持HTTP 协议的客户端编程工具包,并且它支持 HTTP 协议最新的版本。实现了所有 HTTP 的方法(GET,POST,PUT,HEAD 等)支持 HTTPS 协议支持代理服务器等
OKhttp3
OKHttp是一个当前主流的网络请求的开源框架, 用于替代HttpUrlConnection和Apache HttpClient支持http2.0,对一台机器的请求共享一个socket。采用连接池技术,可以有效的减少Http连接数量。无缝集成GZIP压缩技术。支持Response Cache,避免重复请求
域名多IP支持
RestTemplate
Spring RestTemplate 是 Spring 提供的用于访问 Rest 服务的客户端,RestTemplate 提供了多种便捷访问远程Http服务的方法,能够大大提高客户端的编写效率,所以很多客户端比如 Android或者第三方服务商都是使用 RestTemplate 请求 restful 服务。

  1. 面向 URL 组件,必须依赖于主机 + 端口 + URI
  2. RestTemplate 不依赖于服务接口,仅关注 REST 响应内容
  3. Spring Cloud Feign 是基于RestTemplate实现

6.2 使用RPC框架进行服务间通信

在RPC最初出现时,大家都奔着让计算机调用远程服务跟调用本地服务一样。“透明的RPC调用一成为主流”。但是后来发现,这样让人们误以为通信是没有成本的,后来还出现了 “通过网络进行分布式运算的八宗罪”。这八宗罪就是程序员在网络编程中经常忽略的问题。所以后面RPC就不能等同于IPC去实现,不能奔着透明化去走。

  • RPC全称为remote procedure call,即远程过程调用,借助RPC可以做到像本地调用一样调用远程服务,是一种进程间的通信方式 。
  • RPC协议可以基于HTTP 例如Web Service 、也可以基于TCP协议进行传输
  • RPC框架解决的问题主要是 1 传递数据 2表达数据 3标识方法

常见的RPC框架有一下几种。
Java RMI
Java RMI(Romote Method Invocation)是一种基于Java的远程方法调用技术,是Java特有的一种RPC实现。

Hessian
Hessian是一个轻量级的remoting onhttp工具,使用简单的方法提供了RMI的功能. 相比
WebService,Hessian更简单、快捷。采用的是二进制RPC协议,因为采用的是二进制协议,所以它很适合于发送二进制数据。

Dubbo
Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和Spring框架无缝集成。Dubbo是一款高性能、轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。

gRPC
gRPC是由Google公司开源的一款高性能的远程过程调用(RPC)框架,可以在任何环境下运行。该框架提供了负载均衡,跟踪,智能监控,身份验证等功能,可以实现系统间的高效连接。