字节后端青训营笔记——架构篇

架构

一、什么是架构

架构，又称软件架构，是有关软件整体结构与组件的抽象描述用于指导软件系统各个方面的设计。

• 面向服务的架构（Service-Oriented Architecture，简称SOA）是一种软件设计和软件架构模式，他有两个关键要素：

  • 将应用的不同功能单元抽象成服务。
  • 定义服务之间的通信标准。
    

• 微服务架构：SOA的去中心化。

二、企业级后端架构剖析

2.1 云计算

• 云计算是一种提供按需自助服务、广泛网络访问、资源池化、快速弹性、按使用量付费的计算服务模式。它允许用户通过互联网访问和使用存储在远程服务器上的数据和应用程序。
• 云计算的四层：IaaS(Infrastructure as a Service)、PaaS (Platform as a Service)、SaaS (Software as a Service)、FaaS (Function as a Service)

1. IaaS (Infrastructure as a Service)：

   • 定义：基础设施即服务是一种云计算服务模型，它提供虚拟化的计算资源。用户可以通过Internet租用这些资源，如服务器、存储和网络硬件。
   • 控制程度：IaaS提供了最高的控制程度，用户可以完全控制操作系统安装、应用程序部署和网络配置。
   • 例子：Amazon Web Services (AWS) 的EC2、Google Compute Engine (GCE)、Microsoft Azure的虚拟机。

2. PaaS (Platform as a Service)：

   • 定义：平台即服务是一种云计算服务模型，它提供了一个平台，允许用户开发、运行和管理应用程序，而无需构建和维护底层硬件和软件基础设施。
   • 控制程度：PaaS提供了一个中间层的控制，用户可以控制应用程序和某些应用程序托管功能，但对底层基础设施的控制有限。
   • 例子：Google App Engine、Microsoft Azure的App Services、Heroku。

3. SaaS (Software as a Service)：

   • 定义：软件即服务是一种云计算服务模型，它通过Internet提供应用程序，用户通常通过订阅模式访问这些应用程序。
   • 控制程度：SaaS提供了最低的控制程度，用户只能使用应用程序的功能，而不能控制应用程序或其运行环境。
   • 例子：Google Workspace（以前的G Suite）、Microsoft Office 365、Salesforce。

4. FaaS (Function as a Service)：

   • 定义：函数即服务，也称为无服务器计算，是一种云计算服务模型，它允许用户运行代码而无需管理底层的运行环境或基础设施。
   • 控制程度：FaaS提供了一种事件驱动的计算模型，用户只需上传代码，服务提供商会处理其余的工作，包括自动扩展、负载均衡和状态管理。
   • 例子：AWS Lambda、Google Cloud Functions、Azure Functions。

每种服务模型都有其特定的应用场景和优势：

• IaaS适合需要高度控制和自定义基础设施的用户。
• PaaS适合开发者，他们希望快速开发和部署应用程序，而不需要管理底层基础设施。
• SaaS适合最终用户，他们需要直接使用应用程序，而不需要关心应用程序的运行环境。
• FaaS适合需要快速响应事件和处理短暂任务的场景，它可以帮助用户降低成本和提高可扩展性。

2.2 云原生

• 云原生,实际是云原生(计算)的简称,它是元计算发展到现在的一种形态。云原生技术为组织(公司)在公有云、自由云、混合云等新型的动态环境中,构建和运行可弹性拓展的应用提供了可能。
• 云原生主要涉及四个大方面：
  • 弹性资源:基于虚拟化容器以及灵活的编排调度机制,可以为云服务提供快速扩缩容能力,而且极大程度地提高了物理资源的利用率。在这方面, kubernetes技术已经称为了业界的标准
  • 微服务架构:还记得前面我们聊到的微服务架构么?没错,它也是云原生的重要基石之一。依托于功能单元解构,使得云服务具备了快速迭代的可能,业务得以迅速发展;统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭,同时也使得各组件之间的交互变的更容易
  • DevOps:设计->开发->测试->交付->开发->测试->交付，自动化的流程使得软件的工作流程更高效，将微服务架构的优势发挥的淋漓尽致
  • 服务网格:如果说微服务架构的重要进步,是将庞大的单体服务按照业务功能解耦开来,那么,服务网格的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不再需要关心异构系统中RPC中间件治理能力的不统一,也使得复杂的治理能力的落地成为可能
    

2.3 RPC

2.3.1 RPC简介

RPC（Remote Procedure Call，远程过程调用）是一种计算机通信协议，它允许一个程序（客户端）通过网络向另一个程序（服务器）请求服务，而无需了解底层网络技术的细节。RPC协议抽象了网络通信的复杂性，使得开发者可以像调用本地函数一样调用远程服务器上的函数或方法。

RPC的主要特点包括：

1. 透明性：对于开发者来说，调用远程过程就像调用本地过程一样，无需关心网络通信的细节。

2. 协议抽象：RPC框架负责处理网络通信、数据序列化和反序列化等底层细节。

3. 语言无关性：RPC允许不同编程语言编写的程序之间进行通信，只要它们遵循相同的RPC协议。

4. 分布式计算：RPC是实现分布式系统和微服务架构的关键技术之一，它允许服务在不同的机器和进程之间进行通信。

2.3.2 RPC与HTTP比较

RPC（Remote Procedure Call）协议本身并不严格对应于OSI模型或TCP/IP模型中的某一层，因为它跨越了多个层次来实现其功能。然而，我们可以将RPC的关键组成部分与网络模型中的层次进行比较：

1. 表示层：RPC协议需要处理数据的序列化和反序列化，即将程序调用的数据结构转换为可以在网络上传输的格式，这涉及到表示层的功能。

2. 会话层：RPC协议管理客户端和服务器之间的会话，包括建立连接、维护会话状态和结束会话。

3. 传输层：RPC协议依赖于可靠的传输协议（如TCP）来确保数据的可靠传输。RPC框架通常会在传输层之上实现自己的通信机制。

4. 应用层：RPC协议最终在应用层实现，因为它提供了一种让应用程序能够进行远程过程调用的接口。

HTTP（HyperText Transfer Protocol）是应用层的一个协议，主要用来在Web上传输超文本数据。它定义了客户端和服务器之间请求和响应的格式。以下是RPC和HTTP之间的一些比较：

1. 抽象级别：

   • RPC：提供了一种更高层次的抽象，允许开发者像调用本地函数一样调用远程服务。
   • HTTP：提供了一种请求-响应模型，需要开发者手动构建请求和解析响应。

2. 使用场景：

   • RPC：适合构建分布式系统和微服务架构，可以跨越不同的编程语言和平台。
   • HTTP：主要用于Web应用，特别是客户端和服务器之间的通信。

3. 性能：

   • RPC：通常比HTTP更快，因为它可以自定义协议和数据格式，减少开销。
   • HTTP：由于其通用性和附加的元数据，可能会有更大的开销。

4. 跨语言支持：

   • RPC：可以支持多种编程语言，只要它们遵循相同的RPC协议。
   • HTTP：虽然可以通过RESTful API实现跨语言通信，但通常不如RPC灵活。

5. 安全性：

   • RPC：安全性取决于具体的实现，可能需要额外的安全机制。
   • HTTP：有成熟的安全机制，如HTTPS、OAuth等。

6. 可扩展性：

   • RPC：可以设计为高度可扩展，尤其是在微服务架构中。
   • HTTP：也具有很好的可扩展性，尤其是在使用RESTful API时。

2.3.2 RPC与WCF比较

1. 概念和设计：

   • WCF：是微软提供的一套用于构建服务导向应用程序的框架，它允许开发者在.NET平台上构建、部署和管理服务。WCF支持多种通信协议，包括HTTP、TCP等，并且可以与多种不同语言和平台进行互操作。
   • RPC：是一种更为通用的概念，指的是一种允许程序调用另一个地址空间（通常是远程系统）中的函数或方法的机制。RPC可以基于多种协议实现，如TCP/IP、HTTP等。

2. 通信协议：

   • WCF：默认使用HTTP协议，但也支持TCP、命名管道等其他协议。WCF的通信协议选择更加灵活，可以根据不同的应用场景选择最合适的协议。
   • RPC：通常使用TCP/IP协议，但也可以通过HTTP实现。RPC的实现通常更关注于远程调用的语义，而不是传输协议的细节。

3. 性能：

   • WCF：性能取决于所选的绑定和配置。WCF提供了多种优化手段，如异步操作、消息压缩等，以提高性能。
   • RPC：性能通常较高，因为它直接使用二进制数据格式和协议，减少了数据的冗余和解析开销。

4. 跨平台和跨语言支持：

   • WCF：WCF主要在.NET平台上使用。
   • RPC：一些RPC框架如gRPC提供了广泛的跨平台和跨语言支持。

5. 易用性和开发效率：

   • WCF：提供了丰富的配置选项和编程模型，但这也意味着配置和学习曲线可能比较陡峭。
   • RPC：通常更注重简化远程调用的过程，使得开发者可以像调用本地方法一样调用远程方法，从而提高开发效率。

6. 安全性：

   • WCF：提供了一套完整的安全模型，包括传输层安全、消息级安全等。
   • RPC：安全性也取决于具体的实现，但通常RPC框架会提供安全机制，如认证和加密。

三、企业级后端架构挑战与处理策略

3.1 引入离在线资源池与自动扩缩容

业务可以大体分为两种：

• 在线业务：
  • IO 密集型为主
  • 具有潮汐性、周期性
  • 例如高并发的请求
• 离线业务：
  • 计算密集型为主
  • 非实时性
  • 如用户画像分析

可以在同一台宿主机上引入离在线资源池：

根据CPU和内存的部分指标进行动态扩缩容：

3.2 微服务亲和性部署与流量调度

• 业务A和业务B看似没有什么关系，但是真正运行起来发现他们之间存在大量的互相调用，那么我们可以把业务A和业务B按照比例（例如1:1）部署到同一台宿主机上，减少远程的RPC调用。
• 但是除了宿主机自身业务A和业务B的交流，肯定还有远程的RPC调用，那么我们可以用 Service Mash 控制面进行流量调度，通过资源指针的方式判断宿主机的负载。

四、后端架构实战

4.1 自适应静态权重

这个就是流量调度最基础的实现。

4.2 自适应动态权重 Alpha

通过动态权重决策中心计算各个服务的权重，如果发生异常就返回静态权重，解决了无紧急回滚能力的缺陷。

4.3 自适应动态权重 Beta

不光采集宿主机上的数据，还采集RPC指标，进行更复杂的计算，并存到时序数据库中。

4.4 决策中心微服务化

五、尾声