凤凰架构 - 读后整理

凤凰架构

---

探索起步

• 前端工程
  • 将前端文件部署到一个服务器上，静态访问
• 单体架构: Spring Boot
  • 所有业务或技术相关都在一个服务中
• 微服务: Spring Cloud
  • 拆分了业务，如订单，付款，账户，认证等
  • 但仍需要部署技术相关的服务，如服务发现，服务监控，配置中心
• 微服务: Kubernetes
  • 将技术的东西剥离(但并非全部，认证还保留着)，让Kubernetes 去做，如服务监控，服务发现
• 服务网格: Istio
  • 每个服务就是一个ServerMesh，使用边车代理（Sidecar）来代理用户到业务服务之间的流量，做进一步的控制。
• 无服务: AWS Lambda
  • 函数既服务的概念，将业务代码放入三方管理，由三方自动分配资源，或做加密认证等。重量级的Java程序还不适用，除非使用GraalVM 做提前编译、将 Spring 的大部分 Bean 提前初始化，或者迁移至Quarkus这以原生程序为目标的框架上，否则是很难实际用于生产的

演进中的架构

• 原始分布式时代

  • 研究人员在想各种办法实现分布式协调而创建出了许多应用再分布式系统上的协议与组件。

• 单体系统的的时代

  • 大型单体系统所有的交互都是在同一个进程内，但是项目结构庞大，尽管使用了包结构分层。

• SOA(面向服务架构)时代

  • 从烟囱式架构(自身系统与外界没有任何交集)到微内核架构(插件式集成其他模块), 再到事件驱动架构(外界消息以事件方式进入管道，内部系统订阅感兴趣的事件)

    这时就需要了ESB（Enterprise Service Bus）来管理各个消息了。

• 微服务时代

  • 虽然始于SOA的替代，但是终于自我的创新。
  • 在摈弃了SOA的许多设计的同时，追求更加自由的实现。这使得微服务时代充斥着迷茫的选择，对架构设计的难度也提升了很多。

• 后微服务时代

  • 由于硬件跟不上软件的灵活性 并且 2017 kubernetes 在容器领域取得胜利后，微服务时代进入了容器时代，使用容器治理服务。

• 无服务时代

  • Baas+Faas结构的一种架构方式，算力，服务器性能，中间件等非业务的模块由三方服务商管理，开发人员只需要将业务代码装成Faas即可。但由于是冷启动，对java不友好现在。

架构师的视角

• 访问远程服务
  • 远程服务调用
    • 讲述RPC的发展历程，以及问题所在。（表示数据[序列化]、传递数据[应用层传输协议]、表示方法[不同语言方法表示不同]， 不同的框架用的协议不同，性能不同，尚未统一）
  • REST设计风格
    • 另辟蹊径的一种远程服务调用设计模式，将自身与http协议绑定，解决了传递数据，利用HTTP的规范当中资源操作的方式。由于走HTTP，也带来了一些性能或安全的问题有待解决。
• 事务处理

  ACID 中，C 是目的，AID 是手段。
  
  Consistency (一致性)。
  
  Atomic (原子性)：要么都成功，要么都失败；没有中间状态；
  
  Isolation (隔离性)：多业务读/写时保证相互独立；
  
  Durability (持久性)：已提交的数据保证持久化，不会丢失。

  • 本地事务：单一数据源保持ACID
    • 锁
      • 写锁（X）：记录被加锁写锁就不能被其他事务读写
      • 读锁（S）：记录被加了读锁，可以被其他事务读，但是只有由自己写
      • 范围锁 ：范围内的记录都不能变，并且不能在范围内插入新记录
    • 数据库的四种隔离级别
      • 串行化 使用读写锁+范围锁
      • 可重复读 使用读写锁， 所以会有幻读
      • 读已提交 使用写锁，读完就释放了读锁， 脏读
      • 读未提交 每次操作完就释放锁 强化了脏读
  • 全局事务： 多个数据源之间的ACID
    • 由全局事务管理器来处理所有数据源之间的数据，性能较差，容错低
    • 数据库的XA
    • 2PC/3PC
  • 共享事务：同一个数据源共享给多个服务
    • 缺点： 如果这样做，那就需要找更好理由支持 为什么使用微服务， 以及数据库压力增高
    • 优点： 由一个全局事务变成了本地事务
  • 分布式事务
    • 最大努力交付： 采用持续循环的方式重试失败的场景
    • TCC （try-confirm-cancel）: 用户代码上的实现，并不是基础设施实现。
    • SAGA ： 将一个事务拆分成多个小事务，确保最终一致性，失败进行补偿
• 透明多级分流系统

  透明即无感知，多级分流则为服务中各种软硬件各司其职，缓存做好缓存的功能，网关做好流量分发，DNS做好域名解析

  • 客户端缓存：强制缓存有在response的请求头上设置 Expires 或者 Cache-Control ;协商缓存有 Last-Modified 和 Etag， 前者是秒级别的
  • 域名解析： local DNS -> 根域名服务器 -> 权威域名服务器，递归式查找，使用任播方式
  • 传输链路： http2使用多路复用(一连接多流-请求)解决了TCP多连接问题； 使用Gzip来压缩请求的大小； Http3 使用 QUIC 来实现快速连接； – 每项技术背后都存在优点和缺点
  • 内容分发网络：建立一群存储资源的站点，当网站需要资源时，从最近的一台资源机获取，如果资源机没有则回源地址取。 资源机的缓存机制可以自己实现
  • 负载均衡： X层负载均衡是指在七层的某层做负载均衡， 如二层负载均衡指修改帧中的MAC来实现负载均衡，三层指修改目标地址的ip地址来实现，四层是TCP直接转发，七层是应用层代理，虽然效率不如四层，但是贵在花样多。
    • 负载均衡算法： 轮循均衡，权重轮循均衡，随机均衡，权重随机均衡，一致性哈希均衡，响应速度均衡，最少连接数均衡
  • 服务端缓存： 使用进程缓存或者缓存中间件，但是有缓存击穿 (没有key导致的) 或者 缓存穿透 (有key，但是莫名失效导致) 或者 缓存雪崩 (同时大批量key失效导致的) 或者 缓存污染 (数据源和缓存数据不一致) 的风险
    • 对于缓存击穿，缓存穿透的解决方案有： 对key加同步锁，设置value=null的key，并设置默认失效时间，布隆过滤器
    • 对于缓存雪崩，就可以分散失效时间
    • 对于缓存污染，先读缓存后读数据源，先写数据源后失效缓存
• 架构安全性
  • 认证： 识别用户是谁， TCP三次握手，Web Authentication， 生物识别认证
  • 授权： 识别用户有哪些权限，RBAC, OAuth2的四种模式
  • 凭证： 证明用户身份的凭证，如JWT，sessionId, jsessionId
  • 保密： 对称加密，非对称加密，摘要算法，都是对消息的保密措施
  • 传输： Http 和 Https，增加TLS，用一来一回的hello请求并添加随机参数，再各用一次handshakeFinished来确定了通讯过程中使用的对称密钥。 TLS让服务器和客户端生成了同样的对称加密密钥，这要保证消息只有两个人自己知道。
  • 验证： 格式校验与业务校验都是为了保证数据的可靠性
• 分布式的基石

  重点： 如果保证分布式系统的一致性，在可用性和一致性之间的取舍

  • 分布式共识算法
    • Paxos: 由 提案节点，决策节点，记录节点三种角色组成。 每个节点可以担任多个职位，并且遵守两个承诺一个应答原则。
    • Multi-Paxos: 对Paxos存在的问题提出的一种优化算法，增加了选主来处理存在的活锁问题。
    • Gossip: 流言算法、瘟疫算法， 每个节点将信息传播给与自己相连的节点，保证最终一致性
  • 从类库到服务
    • 服务发现：微服务中的服务相互发现，可以用注册中心中间件，或者由基础设施实现。 需要保证可靠和可用
    • 网关路由：服务对外时都需要配置一个网关，来进行权限校验，限流，分流等处理。
    • 客户端负载均衡：对服务做负载均衡时需要考虑的点 -> 延迟，可用性，跨地域和区域场景
  • 流量治理
    • 服务容错: 快速失败，安全失败，重试等方法以便解决服务调用异常
    • 流量控制：TPS/QPS/HPS, 防止服务不可用，需要做流量控制，如流量计数器、滑动时间窗、漏桶和令牌桶， 分布式限流可以在网关给每个请求分配货币额度，每个请求消耗一定额度的货币，没钱了就限流
  • 可靠通讯
    • 零信任网络：边界安全模型与零信任度安全模型构建
    • 服务安全：安全包含认证和授权，如何安全的认证
  • 可观测性
    • 事件日志: 输出(app) -> 收集和缓存(redis/kafka) -> 加工与聚合(logstash) -> 存储与查询(es,kibana)
    • 链路追踪: 三种实现(基于日志的追踪,基于服务的追踪,基于边车代理的追踪), 规范：OpenTelemetry
    • 聚合度量: 收集系统的信息做分析，使用增多改少的时序数据库来加速查询和承载庞大数据，分析后需要支持发送预警。 (度量系统包含：收集->分析->预警) Prometheus
• 不可变基础设施
  • 从微服务到云原生: 云上部署升级比自建机更快更方便，而且不需要关心硬件问题
  • 虚拟化容器
    • 容器的崛起: 隔离文件(chroot) -> 隔离访问 (namespace) -> 隔离资源(cgroups) -> 封装系统(LXC) -> 封装应用(Docker) -> 封装集群(kubernetes)
    • 以容器构建系统: Kubernetes 的设计理念：隔离与协作 (容器资源隔离，但每个容器又可以相互协作 如pod), 韧性与弹性(集群的容错处理以及滚动更新)
    • 以应用为中心的封装: 为了让开发运维基础设施提供方各司其职而产生的技术或方案，现在还没统一规范，许多技术也是在kube上再封装一层，毕竟技术就是套娃 (chroot、[namespaces、cgroups - LXC 底层] 内核能力-> LXC -> docker -> kube)
  • 容器间网络
    • linux 网络虚拟化: 所有的网络都是基于linux网络开发的。在网络通讯过程中设置很多钩子(回调函数)来让其功能更丰富。 案例 局域网之间的通讯
    • 容器网络与生态:CNM 和 CNI之争，最终kube的CNI胜利了。网络的插件大多都是overlay（二三层），underlay(一二层)
  • 持久化存储
    • Kubernetes存储设计:
      • 静态存储：存储申明通过管理员申明PV，用户声明PVC，运行时PVC会去寻找匹配的PV作用于pod中。
      • 动态存储：使用StorageClass申明，在PV寻找PVC时，StorageClass会动态生成一个符合的PV用于给PVC绑定
    • 容器存储与生态: kube中基于CSI(容器存储接口)实现的可插拔式功能。 存储系统包含 快存储，文件存储，对象存储
  • 资源与调度：
    • 资源分配时，可以设置requests和limits 来限制pod的资源。pod有三种优先级， Guaranteed > Burstable > BestEffort。
    • kube在分配pod时，为保证各个node资源平衡，node资源越多，pod被分配到该node的可能越大。调用时的策略包含 通用过滤策略，卷过滤策略，节点过滤策略
  • 服务网格 (数据平面和控制平面)

  数据平面由一系列边车代理所构成，核心职责是转发应用的入站（Inbound）和出站（Outbound）数据包，因此数据平面也有个别名叫转发平面（Forwarding Plane）。同时，为了在不可靠的物理网络中保证程序间通信最大的可靠性，数据平面必须根据控制平面下发策略的指导，在应用无感知的情况下自动完成服务路由、健康检查、负载均衡、认证鉴权、产生监控数据等一系列工作。
  
  控制平面的特点是不直接参与程序间通信，而只会与数据平面中的代理通信，在程序不可见的背后，默默地完成下发配置和策略，指导数据平面工作。控制平面通常也会附带地实现诸如网络行为的可视化、配置传输等一系列管理职能

  • 透明通信的涅槃: 想要通讯变得透明，就要隔离业务功能和非业务功能，边车代理是一条路径，让流量发放，认证授权，限流容错都在业务进程外处理，使得业务进程无感知。 (功能如 服务网格 Istio 和 Envoy)
  • 服务网格与生态: 服务网格接口(SMI) 在逐步形成，数据平面和控制平面的产品也越来越多。
• 技术方法论
  • 向微服务迈进：寻找为何要靠向微服务
    • 目的：微服务的驱动力 -> 减少成本，敏捷开发
    • 前提：微服务需要的条件 -> 执行者决策 + 有能力设计 + 自动化部署能力
    • 边界：微服务的粒度 -> 基于性能+可用性+数据一致性考虑，服务至少具有功能完备+可独立部署
    • 治理：理解系统复杂性 -> 复杂在模型认知负荷+庞大微服务系统的协调。 治理：持续的管理。 如不，可能面临推到重来

两个披萨原则： 如果两个披萨喂不饱一个开发团队，那么这个团队可能就显得太大了，因为人数过多的项目会议将不利于决策的形成。
奥卡姆剃刀原则： 如无必要，勿增实体
康威定律：

1. 组织沟通方式会通过系统设计表达出来
2. 时间再多一件事情也不可能做的完美，但总有时间做完一件事情
3. 线型系统和线型组织架构间有潜在的异质同态特性
4. 大的系统组织总是比小系统更倾向于分解

解读： 有怎样结构、规模、能力的团队，就会产生出对应结构、规模、能力的产品。

学习：编译原理的龙书，计算机体系结构和程序运行的CSAPP，分布式与数据库原理的DDIA、操作系统原理的MOS，等等。这些书系统严谨全面，但可读性并不优秀，在B站/Coursera刷这些书作者们的公开课翻译视频也许是更好的方法。