阿里云云原生学习及思考笔记-云原生理解

1.什么是云原生
真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。
云原生是指从云的原生应用角度出发，一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。[1]

从这个角度来看，与云原生对应的是传统的部署方式。用来对比的是云原生应用和传统应用。

云原生的发展脉络[1]

2.API，容器，微服务之间的关系又是如何？
API 是应用程序编程接口（Application Programming Interface）的缩写。维基百科指出，“总的来说，它是各种组件之间的一组明确定义的通信方法”。
现如今，当人们谈论 API 时，他们通常指的是通过 HTTP 端点公开的远程接口。为了区分这些远程 API 和上面提到的本地系统 API，我将用术语“Web API”指代远程 API。
我们通过底层设计范式（如查询、RPC 或 RESTful）或协议（如 SOAP、gRPC 或 GraphQL）进一步对远程 API（或 Web API）进行分类。除此之外，我们还通过目标受众来区分 API，将它们分为公共、合作伙伴或私有 / 内部 API。
微服务，又叫微服务架构，是一种软件架构方式。它将应用构建成一系列按业务领域划分模块的、小的自治服务。
在微服务架构中，每个服务都是自我包含的，并且实现了单一的业务功能。简单来说，就是将一个系统按业务划分成多个子系统，每个子系统都是完整的，可独立运行的，子系统间的交互可通过HTTP协议进行通信（也可以采用消息队列来通信，如RoocketMQ，Kafaka等）。[3]
与微服务相对比的是单体架构，一个比较形象的例子区别单体架构和微服务是装配式建筑。传统建筑（单体应用）的施工周期（开发时间）很长，往往依赖于建筑公司（开发团队）的能力和水平，修建完成后难以搬迁和复用，而装配式建筑（微服务）的梁、板、柱、墙等构件（单个服务）可以事先批量化的在工厂（容器）生产，而在建造过程中，我们可以把构件想象成一块块乐高积木，在施工现场只需把它们拼合在一起，大大提升了施工进度和建筑质量。[5]
一组服务可以运行在tomcat容器内，服务间采用轻量级通信机制，如HTTP RESTful API，独立自动部署，可以采用不同的语言及存储方式。[5]
如果没有容器，要么把服务器配置成可以运行多个微服务，让这些微服务不可避免地相互产生负面干扰，要么每个微服务都需要一个单独的服务器或自己的虚拟机，导致不必要的开销。因此，微服务通常被部署在一组由容器集群软件（如 Kubernetes）管理的一组容器中。可以肯定地说，容器和微服务的崛起其实是相互影响、相互促进的结果。【此处强调的是容器的隔离性，以前为了保证隔离性，需要分别部署在不同的VM上，但是这样也导致了启动时间长（相较于容器的秒级启动）；其次，对服务代码进行容器化，它的运行环境、依赖关系、系统库等，都被打包在一起，保证了环境的隔离。】

不同的隔离级别[8]

基于微服务架构构建的应用程序或 API 不仅要把自己完全暴露出来，还需要在内部组件（微服务）之间建立连接。由于每个微服务都可以使用不同的编程语言实现，我们需要依赖标准协议（如 HTTP）来建立微服务之间的连接。这个时候我们就回到了 API 上。[2]

提到了API，我们不得不提及API管理与API集成。
1、全生命周期API管理
API 全生命周期管理（Full Life Cycle API Management）是指对 API 从规划、设计到实施、测试、发布、运行、调用直至版本变更与退出的整个周期的管理。7
2、API网关：微服务基础设施
全生命周期API管理里一个细分的领域是API网关（API Gateway），API网关顾名思义，是出现在系统边界上的一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，主要起到隔离外部访问与内部系统的作用，并处理常见的南北向流量。[5]
API网关作为企业能力开放的一个门户，除了具备基本的请求转发、协议转换、路由等功能，以及高性能和高稳定性外，还需具备良好的扩展性[5]

API网关：微服务基础设施

Uber的微服务架构[5]

微服务通用框架[6]
因为微服务是功能粒度上的拆分，必然导致拆分之后的模块变多。针对模块与模块之间的通信与维护，又演变出如下问题：
模块与模块之间如何通信；
每个被拆分的微服务如何做负载均衡；
服务如何做注册，如何做发现；
服务之间调用如何做限流，服务调用失败如何做降级，流量异常如何做熔断；
服务调用是否可以做统一的访问控制；

ESB与API网关
https://blog.csdn.net/aeaiesb/article/details/107661866

目前国内用的最多的无外乎是两套框架：Dubbo，Spring Cloud。Dubbo大家都很熟悉，从开源到无人维护再到重新冲击Apache顶级项目。但是Dubbo更加准确来说是一个分布式服务框架，致力于提供高效的RPC远程服务调用方案以及SOA服务治理方案。说白了就是个分布式远程服务调用框架。
Spring Cloud 基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。[6]
微服务架构最常见、最广泛使用的框架是基于Java的Spring Cloud（集成了上图里的Netflix OSS技术栈），提供了服务发现、负载均衡、故障转移、动态扩展和数据分区等功能，已经成为微服务的最佳实践。
但是Spring Cloud构建在Java虚拟机之上，不能满足高并发下的性能要求，所以许多开源产品层出不穷，其中也包括中国互联网企业所贡献的微服务框架，例如华为的ServiceComb、阿里的Dubbo等等。[5]

另外，提及了API网关，就不得不提及服务网格
服务网格和API网关是两个联系非常紧密的概念，它们的用途既不同，但是在某些方面又相互重叠。在某种程度上，我们可以认为服务网格是一个分布式的、微观层面的API网关，解决微服务服务发现、负债均衡、流量控制等需求。在具体用途上，API网关处理的是所谓南北向流量即内外部请求；而服务网格处理的是东西向流量即内部服务相互间的访问。想深入了解两者区别的读者可以仔细阅读《Service Mesh和API Gateway关系深度探讨》这篇文章。[5]

3.DevOps与CI/CD呢？
DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。
对于DevOps，微服务不是必须的，但微服务为DevOps提供了最好的架构支撑，对于组织和流程的要求也是一致的。所以，也有人称微服务是DevOps架构。

另一个角度来说，DevOps是配合微服务的理念组织构建团队协作的方式，各团队可以独立开发，测试、发布和迭代各自的微服务，互不干扰，沟通协调成本小。[5]

如果你将微服务打包为容器的一部分，容器镜像就成为一个部署单元，DevOps团队只需要知道如何部署容器就可以了，不需要去考虑里面运行的是什么应用。通过这种方式，你也能够避免由于缺少依赖库，或者环境版本(比如你的服务所需要的框架、依赖)不匹配所造成的服务失败，服务所需要的所有的东西都被打包在一起，成为一个不可变的环境，这就是典型的持续集成的一部分。[8]
持续集成（CONTINUOUS INTEGRATION，CI）指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。

与持续集成相比，持续交付（CONTINUOUS DELIVERY，CD）的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。
持续部署（CONTINUOUS DEPLOYMENT）指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比，持续部署强调了通过自动部署的手段，对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。
DevOps、持续集成、持续交付、持续部署并不是某种技术栈或者框架，而是开发文化、流程、理念和操作方式。[4]

[1]云原生时代（一）云原生及CNCF基金会https://zhuanlan.zhihu.com/p/143417185
[2]别再管你的 API 叫微服务了：容器、微服务和API之间是什么关系？cloud.tencent.com/developer/news/378771
[3]微服务是什么https://zhuanlan.zhihu.com/p/66190538
[4]云原生时代（二）：DevOps与CI/CDhttps://zhuanlan.zhihu.com/p/143424111
[5]云原生时代（三）：微服务、API管理与集成https://zhuanlan.zhihu.com/p/143472291
[6]微服务全流程分析https://zhuanlan.zhihu.com/p/101417273
(文章基于Dubbo，Spring Cloud架构内，各组件做了详细拆解分析，针对两种微服务架构初期学习非常有帮助）
[7]为什么我们说云原生时代，企业数字化转型更需要做好 API 全生命周期管理？https://developer.aliyun.com/article/793174
[8]从微服务开始(二)：容器与微服务https://blog.csdn.net/steelren/article/details/77162713