云计算学习路线之云原生(百度云智学院学习笔记)

理解云原生基本概念及分布式容器设计模式

1. 云原生技术的前世今生
2. 走近微服务新时代：服务网格
3. 分布式系统的容器设计模式

云原生技术的前世今生

自从云原生概念诞生以来，云原生的定义就一直在持续的发展

云原生是IT架构与方法论

云原生不只是一系列技术的组合 ,而是一套适用于云计算时代的T架构与方法论, 包括容器化、微服务、DevOps、持续交付等主题。它的核心是通过优化应用的架构设计、开发流程和部署、运维方式,让云计算的弹性、灵活、自动化优势得到充分发挥,使得工程管理和基础设施管理变得更加高效和自治,从而帮助管理者将精力集中到业务创新之中。

云原生的实现路径

1. 容器化
   应用细粒度拆分
   容器化交付

2. 镜像&运行时
   容器镜像仓库
   容器运行时

3. CI&CD
   构建持续集成和持续部署工作流
   实现自动化的测试、灰度、回滚

4. 容器与应用编排
   容器编排调度
   应用定义与编排

5. 观察与分析
   应用监控
   日志分析
   请求追踪

6. 网络性能与安全
   容器网络管理
   网络性能优化
   安全策略控制

7. 信息流与信息
   引入RPC框架
   分布式消息中间件

8. 服务器网关与路由
   服务注册与发现
   服务路由管理
   负载均衡与健康检查

9. 持久化存储
   计算存储分离
   分布式数据库&缓存
   云磁盘、对象存储、分布式文件系统

微服务是什么?

“将单个应用程序拆分成多个独立运行的小型服务;服务间基于轻量级机制通信,比如基于Http协议的Restful API ;每个服务承担独立的业务功能,并且能够独立部署;服务通过去中心化的方式进行管理;服务可以各自使用不同的编程语言,并使用不同的数据存储技术。”

微服务框架及平台解决的问题

流行的微服务架构方案

走近微服务新时代：服务网格

什么是服务网格

“A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.”

                          – William Morgan

翻译过来就是:

Service Mesh是一个处理服务通讯的专门的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，对应用服务透明。

总结一下就是:

• 本质:基础设施层
• 功能:请求分发
• 部署形式:网络代理
• 特点:透明

为什么需要微服务网格

• 分布式环境下存在的诸多网络问题，为了解决这些问题，提高系统的 容错能力和可用性，出现了服务注册与发现、负载均衡、熔断、降级、限流等等和通信相关的功能，而这些才是「 微服务框架」要真正处 理的问题。
• 现有的微服务架构下，为解决可能出现的网络通信问题，提升系统的 弹性，开发人员不得不花费大量时间和精力去实现流量控制相关的非业务需求，不能聚焦在业务本身。

服务网格的三个技术优势

1. Observability可观察性

• 服务都被监控为“黑盒”，服务网格捕获诸如来源、目的地、协议、URL、状态码、延迟、持续时间等线路数据。
• 服务的可观察性一般是通过指标度量、日志、分布式追踪三个方式展现的，目前的Service Mesh产品可以很容易和和主流的后端设施整合，提供给应用系统完整的监控能力。

2. Traffic Control流量控制

• 通过Service Mesh,我们可以为应用提供智能路由(蓝绿部署、金丝雀发布、A/B test)、超时重试、熔断、故障注入、流量镜像等各种控制能力。
• 由于它们的设计目的是有效地将来源请求调用连接到其最优目标服务实例，所以这些流量控制特性是“面向目的地的”。

3. Security安全

• 服务的认证
• 服务间通讯的加密
• 安全相关策略的强制执行

服务网格的局限性

• 增加了复杂度
• 运维人员需要更专业
• 延迟
• 平台的适配

分布式系统的容器设计模式

云原生的分布式系统中常见的容器设计模式，包括Init container，Sidecar，Ambassador等模式，以及适用范围和使用注意事项等，并用简单的例子介绍这些模式。

• 之前设计和实现,基本都是从头做起,因为没有什么成熟可用的模块或者组件可以重用

• 进入云原生时代,容器(Docker)和容器编排(K8S)的出现,极大的改变了分布式系统的设计和开发,因为我们有了可以重用的组件

Init Container Pattern

• Init Container Pattern就像Java语言的初始化函数

• Pod中的Init container起的作用也是用来初始化

适用条件:
App Container需要满足一些前置条件

• Case 1:需要等待外部依赖服务ready才能启动(例如DB Service )
• Case 2:需要更新文件,但是此更新逻辑不适合放在App Container中(例
  如从github.上拉取最新文件)

Sidecar

功能:

• 同时调度在同一个Pod里面
• 互相交互效率更高
• 可以共享资源,例如文件

使用Sidecar的好处:

1. App Container和Sidecar Container是解耦的
   ●符合单一职责( Single Responsibility )
   ●Sidecar Container可被复用到其他地方
   ●他们可以被不同的Team来维护和迭代
2. 同时资源隔离提升了健壮性
   ●Sidecar fail ,并不影响App Container

什么时候使用Sidecar Pattern:

• 当这两个Containers需同时部署到同一个host上,但是各有自己的职责
• 这个Sidecar container跟app container共享lifecycle ,但是可以分别去
  迭代和演进,并且还有重用可能

Ambassador

一种特殊的Sidecar