云原生开篇

Thu, 10 Feb 2022 09:23:10 +0000

[toc]

0. 云原生

云原生是一种思想，是一种解决方案，是一种抽象。云原生是从云的原生应用角度出发，是一种构建和运行应用程序的方法，是一套技术体系和方法论Cloud Native Stack，一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。云原生是一个用来描述应用、架构、平台/ 基础架构和流程的形容词，包括研发流程规范，软件架构，基础设施和工具集，是一套不断自我演进的理论体系提供指导思想和最佳实践的组合。谈云原生的本质，不如我们将它理解为一套愿景，一种文化，而不具象为哪些技术体系¹。

您是否能赢得、服务和留住客户，很大程度上取决于能否通过软件应用持续、快速地交付新功能，提供备受认可的业务价值。而云原生就是为了这个价值而努力的手段；

CNCF（云原生计算基金会）

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

VMware Tanzu

云原生是一种利用云计算交付模型的优势来构建和运行应用程序的方法论。当企业使用云原生架构开发和运维应用程序时，它们能更快速地响应客户需求将新想法推向市场。

云原生是关于不需要人类做出决定的自治系统。它仍然使用自动化，但只有在决定了所需的操作之后。只有在系统不能自动确定正确的事情时才应该通知人。具有这些特征的应用程序需要一个能够实际监控，收集度量标准并在发生故障时做出反应的平台。

云原生系统（pivotal公司2017）一般具有如下的特点，：模块化（Modularity）、可观测性（Observability）、可部署性（Deployability）、可测试性（Testability）、可处理性（Disposability）、可替代性（Replaceability）。

0.1 云原生的范围内容

云原生范围	主要内容
方法论与原则	12要素，声明式API
流程规范	DevOps，持续交付，自动化测试，Code Review
软件架构	微服务，服务网格，无服务
基础设施	敏捷基础设施，如K8S、Docker、云服务器、云数据库、云存储等
工具集	Prometheus，Envoy，Jaeger等

0.2 云原生中的代表技术

不可变基础设施

基础设施可编程且不可变的，直接通过API可以对外提供服务，通过代码或者配置来定义一组基础设施，并通过版本化的管理能够保证业务的快速变更。其中的应用载体是不可变的，自包含构建方式以及运行环境，简化应用的更新，删除旧实例，上线新实例。

任何的基础实例（服务器、容器等各种软硬件）一旦创建之后便成为一种只读状态，不对其进行任何更改，如果需要修改或升级实例，唯一方式是创建一批新实例以替换。

Pets Vs Cattle²，宠物和牲口。过去依赖传统的高可靠基础设施，服务的可靠性依赖于高可靠性的服务器，对待服务器就像对待宠物一样，需要实时关注服务的状态并精心维护，系统故障或者升级时候需要通过对服务器进行修复和配置实现。牲口模式下，底层系统故障或者需要升级，直接杀掉后重新创建一个，云原生的架构下底层就是依赖这种模式。

Pets

Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and “hand fed”. Examples include mainframes, solitary servers, HA loadbalancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on.

Cattle

Arrays of more than two servers, that are built using automated tools, and are designed for failure, where no one, two, or even three servers are irreplaceable. Typically, during failure events no human intervention is required as the array exhibits attributes of “routing around failures” by restarting failed servers or replicating data through strategies like triple replication or erasure coding. Examples include web server arrays, multi-master datastores such as Cassandra clusters, multiple racks of gear put together in clusters, and just about anything that is load-balanced and multi-master.

相同的类比是：雪花服务器和凤凰服务器，雪花服务器是手工管理的服务器，需要经常更新和调整，从而形成独特的环境。凤凰服务器总时从0开始构建，并且很容易通过自动化过程重新创建（浴火重生）。

不可变基础设施同不可变变量类似，完成赋值后不能够被修改。运行服务的服务器在完成部署后，就不再进行变更，这一点是通过容器镜像来实现的，是一个自包含、自描述可以完全在不同的环境中迁移的东西。

声明式API

描述最终的状态和幂等性。

容器

作为应用包装的载体。
服务网格

服务网格（Service Mesh）这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等，服务于系统的可观测性、安全性和可靠性。通常是由平台层而不是应用层来实现。
微服务

微服务是一种分布式架构设计理念，为了推动细粒度服务的使用，这些服务要能协同工作，每个服务都有自己的生命周期。一个微服务就是一个独立的实体，可以独立的部署在 Paas 平台上，也可以作为一个独立的进程在主机中运行。服务之间通过 API 访问，修改一个服务不会影响其它服务。

0.3 云原生基础设施

云，它是一种新兴的 IT 基础设施交付方式，通过虚拟化技术，对 IT 硬件资源与软件组件进行了标准化、抽象化和规模化，变成 “产品服务” 和 “账单”（pay as you go）。

Support for cloud native attribute: modularity, operability, elasticity, resilliency;

Gartner 将云原生基础设施划分：Iaas(VMs), Caas(Container), Serverless, Faas

目前更多的AI出现，衍生的Daas，数据即服务，AI与云服务结合产生很多高价值的服务。

1. 云原生应用

云原生应用是一个相互关联但又不独立的组件（service、task、worker）的集合，这些组件与配置结合在一起并在适当的运行时实例化后，共同完成统一的功能目的。云原生应用开发是根据众所周知的云计算技巧与技术构建、运行和改进应用的一种方法。云原生应用是独立的小规模松散耦合服务的集合。

云原生应用程序被设计为在平台上运行，并设计用于弹性，敏捷性，可操作性和可观测性。弹性包含失败而不是试图阻止它们；它利用了在平台上运行的动态特性。敏捷性允许快速部署和快速迭代。可操作性从应用程序内部控制应用程序生命周期，而不是依赖外部进程和监视器。可观测性提供信息来回答有关应用程序状态的问题。

符合云原生架构的应用程序应该是：采用开源堆栈（K8s+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。通过一组架构原则和设计模式，将应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），借助云原生委托大量应用非功能性特性，使业务不再受非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

1.1 云原生应用模型

OAM 全称是 Open Application Model，旨在定义了云原生应用的标准，阿里巴巴和微软共同开源的云原生应用规范模型[^]。云原生中的大部分概念来自于此，对不同平台和场景的逻辑中DevOps做出更高级别的抽象。

开放（Open）：支持异构的平台，容器运行时、调度系统、云供应商、硬件配置等；与底层无关，与供应商无关；
应用（Application）：云原生应用
模型（Model）：应以标准，以使其与底层平台无关；

OAM中定义的术语对象概念：

Workload（工作负载）：应用程序的工作负载类型（如有状态工作负载）对于部署单元的具体描述，由平台提供；
Component（组件）：定义了Workload的实例，并以基础设施中的术语声明其运维特性；
Trait（特性）：用于将运维特性（如弹性、回滚、实例个数等）分配给组件实例；
ApplicationScope（应用作用域）：将组件划分为具有共同特性的松散耦合的应用（如网络/健康）；
ApplicaitonConfiguration（应用配置）：描述Component的部署、包括Trait和ApplicationScope；

云原生应用来说：

基础设施运维：提供不同的Workload类型供开发者使用；
应用运维：定义适用于不同Workload的运维属性Trait和管理Component的ApplicaitonScope；
应用开发者：负责应用组件Component的定义；
应用开发和运维：应用程序全生命周期管理，绑定Component和Trait；

OAM规范原则：

关注点分离：根据功能和行为来定义模型，以此划分不同角色的职责，
平台中立：OAM 的实现不绑定到特定平台；
优雅：尽量减少设计复杂性；
复用性：可移植性好，同一个应用程序可以在不同的平台上不加改动地执行；
非编程模型：OAM 提供的是应用程序模型，描述了应用程序的组成和组件的拓扑结构，而不关注应用程序的具体实现。

1.2 云原生应用12军规

The Twelve-Factor App：云原生应用架构的模式集合³。

更多3项

API声明管理，万物皆服务。你的代码会被一个前端客户端、网关或者其他服务调用；
认证和授权，从一开始就需要考虑设计；
监控与告警，领域相关的监控以及健康数据；

1.3 云原生系统哲学

面向分布式设计（Distribution）：容器、微服务、API驱动的开发；
面向配置设计（Configuration）：一个镜像，多个不同环境配置；
面向韧性设计（Resistancy）：故障容忍和自愈；
面向弹性设计（Elasticity）：弹性扩展和环境（负载）做出响应；
面向交付设计（Delivery）：自动拉起，缩短交付时间；
面向性能设计（Performance）：响应式，并发和资源高效利用；
面向自动化设计（Automation）：自动化的Devops；
面向诊断性设计（Diagnosability）：集群级别的日志、metric和追踪；
面向安全设计（Security）：安全端点、API Gateway、端到端加密

1.4 关于云原生应用的健康报告和遥测数据

健康报告

停止逆向工程应用程序并开始从内部进行监控。 —— Kelsey Hightower，Monitorama PDX 2016：healthz

应用程序应该暴露健康检查以便提高其可操作性和管理自动化；一个常见的手段是提供web服务，返回Http状态码来检查健康状态。对于平台需要更准确的了解应用程序所处的状态，平台需要知道应用程序什么时候开始接受流量，而应用通过该检查来表明自身的健康。

遥测数据

遥测数据是进行决策所需的信息。遥测数据可能与健康报告存在部分重叠，但它们有不同的用途。健康报告通知我们应用程序生命周期状态，而遥测数据通知我们应用程序业务目标。更加关注的应用层面SLO内容，而不是某个节点，确保应用程序的性能处于服务级别目标内。

请求率: 收到了多少个请求？错误: 应用程序有多少错误？时间: 多久才能收到回复？

2. 云原生实践

2.1 CNCF 给出的云原生实践路线图

容器化

一般目前以Docker为主要方式进行容器化。各类应用均可进行容器化，容器化建议服务分割为微服务的方式进行；
CI/CD

创建持续集成持续部署的环境，敏捷的快体现就是快速集成，快速发布。使得整个Devops可以自动从源码进行容器化构建和测试，并部署到生产环境。同时系统可以自动部署、自动回滚、自动测试。
应用定义和编排

Kubernetes作为容器化的应用编排成熟解决方案，目前使首选。Helm Charts能帮助使用者对复杂的Kubernetes应用进行定义、安装和升级
监控和分析

解决方案应该包括监控、日志、和追踪（metrics、logs、tracing），推荐的为Prometheus监控和告警、Fluentd用于日志，而Jaeger用于调用链追踪。
服务代理、服务发现和服务网格

提供健康检查、请求路由方向代理以及负载均衡等。服务发现可以使用CoreDNS, 服务网格目前成熟的使Envoy和Linkerd。
网络和策略

网络需求可以基于CNI兼容的网络解决方案如Flannel或者Weave Net。OPA(Open Police Agent)秉承着“策略即代码”原则，完成通用的策略引擎的基本功能，使用者控制策略和权限确保合规。
分布式数据库与存储

分布式数据库可以获取更好的弹性和伸缩性能。确保横向扩展中，通过sharding的方式保证mysql的横向扩展性，Vitess是一个不错的选择。作为Kubernetes大脑的，etcd提供了集群中以可靠的方式存储数据的能力；需要使用KV存储时候，可以考虑TiKV，其使用Rust编写的高性能的分布式事务级Key-Value解决方案。
流与消息处理

对于json-rest更高性能诉求时候，gRPC或者NATS是一个更好的选择。NATS是一个包含了请求、发布/订阅、复杂均衡队列的多模型消息系统；
镜像私库和运行环境

可以使用Harbor作为镜像私库进行存储以及内容扫描，运行环境需要使用具有OCI兼容性的方案。
软件分发

TLS能够去确保通信的安全，特别是当服务器出现问题后，使用Notary/TUF可以解决这问题，是，使得在软件的分发和更新更加安全。

2.2 Helm包管理

Helm是K8s生态系统中的软件包管理工具，为了以下的目的：

管理、编辑以及更新分散在各处的kubernetes API 对象描述文件；
相关配置文件作为一个应用进行管理，管理应用依赖关系、管理应用版本并发布软件仓库；
分发和重用K8s应用配置；

Helm包中的概念：

Tiller: Helm的服务端，部署在K8s集群中用于处理Helm命令；
Chart： Helm的打包格式，不好了一组相关K8s的配置；
Repository：Helm的软件仓库，该软件仓库保存了Chart软件包以供下载，并提供Chart包清单以供查询；
Release：使用Helm install命令在K8s集群中安装Chart就成为Release

通过一系列的Helm命令，可以创建、校验、打包、绑定repo，搜索、部署、查看、升级、回滚的对应的应用；Helm总有一个字段Revision记录了Release的被更新次数，同etcd中的Revision（Create Revision/Mod Revision等）概念一致，对应于某个时间点的版本信息；

Reference:

安全架构设计

Thu, 29 Apr 2021 12:23:10 +0000

如今，安全对于软件系统越来越重要！公司越大，对于安全方面的考虑也越重视！同时随着当前系统个人数据量激增，隐私保护也日益凸显！

对于任何时候，安全隐私无小事！或多或少会影响，甚至因为安全事故导致公司破产！

当今软件系统已不仅仅是功能正确，对于功能可用只是系统冰山一角，而冰面之下的的内容就是：软件安全、软件可信、软件韧性等非功能性内容。

如何做到系统安全，如何打造稳健的系统？下述内容涉及从宏观角度来看，安全架构、安全设计相关最基本的，以及通用的内容。对于不同形式的软件系统可能涉及的关注点也不同，比如手机终端在组网安全的考虑就比较少。

下述包括8个维度的安全动作内容和8个基本安全设计原则！

如果把任何我们要开发的软件系统比做一场必须要赢得的战争，那安全架构就是战略级的威慑，而安全设计就是战术内容，而安全分析就是软件工程师面对的一场场的战斗，成熟的安全威胁库参考就是历史中发生的一场场的战役，而来自不同方面的安全需求就是我们面临每场战斗的具体战法，解决实际问题最需要的实践。

下面PPT内容详细呈现

Architecture | Liao Lile