字节青训营——架构初探学习笔记

1. 规则引擎

规则引擎是一种嵌入在应用服务中的组件，可以将灵活多变的业务决策从服务代码中分离出来。通过使用预定义的语义模块来编写业务逻辑规则。在执行时接受数据输入、解释业务规则，并做出决策。规则引擎能大大提高系统的灵活性和扩展性。

在字节跳动，规则引擎已经在风控识别、活动运营、配置下发等场景得到了广泛的应用。开发人员可以将业务逻辑与服务代码解耦，实现灵活、高效的业务策略发布。目前公司内部基于规则引擎的动态决策系统已经承接了千万级别QPS的决策请求。

主要涉及到编译原理的部分

1.1 什么是编译

编译的过程就是 把某种语言的源程序，在不改变语义的条件下，转换成另一种语言程序(目标语言程序)

• 如果源代码编译后要在操作系统上运行，那目标代码就是汇编/机器代码。
• 如果编译后是在虚拟机里执行，那目标代码就可以不是汇编代码，而是一种解释器可以理解的中间形式的代码即可。

1.2 解释型语言和编译型语言

• 有的语言提前把代码一次性转换完毕，这种就是编译型语言，用的转换工具就叫编译器，比如C、C++、Go。一次编译可重复执行

  • 编译后产物不能跨平台，不同系统对可执行文件的要求不同。.exe
  • 特殊的，c、c++、汇编、源代码也不能跨平台

• 有的语言则可以一边执行一边转化，用到哪里了就转哪里，这种就是解释性语言，用的转化工具叫虚拟机或者解释器，比如java python、javascript

1.3 关于 Java 和 Python .

• Java既有编译又有解释。但是编译并没有直接编译成机器码，而是编译成字节码，然后再放到虚拟机中执行。
• Python执行过程也是经过两个阶段，先编译成字节码 .pyc 再放到虚拟机中去执行

2. 什么是架构

常见软件架构：

• 单机
• 单体
• 垂直应用
• SOA (Service Oriented Architecture)
• 微服务 (Microservice)

2.1 如何给架构下定义？

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

2.1.1 单机架构

All in one，所有的东西都在一个进程里，部署在一个机器上。

优点：简单

缺点：

• 运维需要停服，用户体验较差
• 承载能力有限。了解下 c10k 问题

2.1.2 单体架构

在单机架构的基础上，将进程部署到多个机器上。

优点：

• 具备水平扩容能力
• 运维不需要停服

缺点：

• 后端进程职责太多，越来越臃肿
• 爆炸半径较大，进程中一个很小的模块出现问题，都可能导致整个进程崩溃

2.1.3 垂直应用架构

在单机架构基础上，将进程按照某种依据切分开。比如，A 软件和 B 软件的后端原先采用单机架构部署，那就是一个进程部署在多个机器上；如果用垂直应用架构，可以将 A 和 B 的后端拆分为 A、B 两个进程，然后再按照单体模式的思路，部署在多个机器上。

优点：

• 一定程度上减少了后端进程职责
• 一定程度上缩小爆炸半径

缺点：

• 没有根本解决单体架构的问题

2.1.4 SOA (面向服务架构)

SOA 架构中，服务为一等公民，将进程按照不同的功能单元进行抽象，拆分为『服务』。有了服务之后，SOA 还为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性。

优点：

• 各服务的职责更清晰
• 运维粒度减小到服务，爆炸半径可控

缺点：

• ESB (企业服务总线) 往往需要一整套解决方案

• 什么是企业服务总线？就是我们常说的 ESB（Enterprise Service Bus）。我们可以把服务总线当成用来连接分布式异构后端和前端系统的一种中间层软件服务，能够隐藏复杂性，简化数据处理过程。这种中间层软件服务通常被认为是一种系统集成组件，而对系统集成需求的剖析引出了服务总线的整体解决方案。

2.1.5 微服务

在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块。有一个 SOA 分布式演进的分支，最终的形态便是微服务。

优点：

• 兼具 SOA 解决的问题
• 服务间的通信更敏捷、灵活

缺点：

• 运维成本

1.什么是API网关

API服务网关是微服务架构里的轻量级的服务总线，解决服务管控和服务治理的相关问题。

API网关是一个服务器，也是进入微服务后端的唯一入口。

2.API网关和ESB总线的区别

API网关和ESB总线最大的区别在于更加的轻量和高性能。为了提高API网关的性能，一般API网关在实现过程中不会去记录详细的数据传输日志。

现从ESB和API网关的使用场景、传输对象、服务契约、实现方式、交互性以及安全层次进行区别分析。

2.1.6 小结

• 架构演进的初衷：满足软件迭代诉求，提高迭代效率
• 架构演进的思路：垂直切分——分布式，水平切分——分层/模块化

3. 企业级后端架构剖析

3.1 云计算

3.1.1 云计算基础：

• 虚拟化技术
  • 硬件层面（VM 虚拟机）- KVM/Xen/VMware
  • 操作系统层面（Container 容器）- LCX/Docker/Kata Container
  • 网络层面 - Linux Bridge/Open v Switch
• 编排方案
  • VM - OpenStack/VMWare Workstation
  • Container - Kubernetes/Docker Swarm

3.1.2 云计算架构：

• 云服务
  • IaaS - 云基础设施，对底层硬件资源池的抽象
  • PaaS - 基于资源池抽象，对上层提供的弹性资源平台
  • SaaS - 基于弹性资源平台构建的云服务
  • FaaS - 更轻量级的函数服务。好比 LeetCode 等 OJ，刷题时只需要实现函数，不需要关注输入输出流
• 云部署模式（拓展）
  • 私有云 - 企业自用
  • 公有云 - AWS/Azure/Google Cloud/Huawei
  • 混合云

3.2 云原生

云原生，实际是云原生（计算）的简称，它是云计算发展到现在的一种形态。

云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。 它的代表技术：

• 弹性资源
• 微服务架构
• DevOps
• 服务网格

3.2.1 弹性资源

基于虚拟化技术，提供的可以快速扩缩容的能力。可以分为弹性计算资源和弹性存储资源两个方面。

弹性计算资源：

• 计算资源调度
  • 在线计算 - 互联网后端服务
  • 离线计算 - 大数据分析。Map-Reduce/Spark/Flinnk
• 消息队列
  • 在线队列 - 削峰、解耦
  • 离线队列 - 结合数据分析的一整套方案，如 ELK

弹性存储资源：

• 经典存储
  • 对象存储 - 视频、图片等。结合 CDN 等技术，可以为应用提供丰富的多媒体能力
  • 大数据存储 - 应用日志、用户数据等。结合数据挖掘、机器学习等技术，提高应用的体验
• 关系型数据库
• 元数据
  • 服务发现
• NoSQL
  • KV 存储 - Redis
  • 文档存储 - Mongo

在云原生的大背景下，不论是计算资源还是存储资源，他们都像是服务一样供用户使用。

3.2.2 微服务架构

微服务架构下，服务之间的通讯标准是基于协议而不是 ESB 的。

• HTTP - H1/H2
• RPC - Apache Thrift/gRPC

如何在 HTTP 和 RPC 之间选择？

• 性能 - RPC 协议往往具备较好的压缩率，性能较高。如 Thrift, Protocol Buffers
• 服务治理 - RPC 中间件往往集成了丰富的服务治理能力。如 熔断、降级、超时等
• 可解释性 - HTTP 通信的协议往往首选 JSON，可解释性、可调试性更好

3.2.3 服务网格

什么是服务网格？

• 微服务之间通讯的中间层
• 一个高性能的 4 层网络代理
• 将流量层面的逻辑与业务进程解耦

没有什么是加一层代理解决不了的问题，服务网格相比较于 RPC/HTTP 框架：

• 实现了异构系统治理体验的统一化
• 服务网格的数据平面代理与业务进程采取进程间通信的模式，使得流量相关的逻辑（包含治理）与业务进程解耦，生命周期也更容易管理