这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记
课前资料
课程PPT：架构初探 - 谁动了我的蛋糕.pptx - 飞书云文档 (feishu.cn)
云原生简介
随着云计算的概念和技术的普及，云原生也随之兴起，无论是应用还是安全，凡是云相关的，都要在云后面加上原生二字。越来越多的企业都已将应用部署到了云上。但是应用上云并不意味着就能充分利用云平台的优势。目前，大部分云化的应用，都是基于传统的软件架构来搭建的，然后再移植到云上去运行，和云平台的整合度非常低，主要表现在以下几个方面：
- 操作系统依赖强：传统应用程序和底层操作系统、硬件、存储和后备服务之间存在紧密的依赖关系，这些依赖关系使得应用程序在跨越云基础设施进行迁移和扩展时非常复杂且有风险。
- 系统紧耦合：传统的企业应用多采用单体架构，将许多不同的功能模块捆绑在一个部署包中，导致功能模块之间产生不必要的依赖，并导致开发和部署过程中丧失敏捷性，无法独立的部署、发布更新、重启。
- 手动化扩展：通过手工管理基础设施，包括手工编写管理服务器、网络和存储的配置脚本。在大规模复杂的操作中，操作人员在诊断问题时会很慢，而且无法大规模地实施。手工制作的自动化脚本还有可能将人为错误硬编码到基础设施中。
- 恢复缓慢：基于虚拟机的基础设施相对于基于微服务的应用程序来说，是缓慢而低效的。因为单个虚拟机启动/关闭的速度很慢，并且在部署应用程序代码之前就会带来巨大的开销。
- 瀑布开发：传统应用的开发模式，IT团队定期发布软件，通常间隔几周或几个月。尽管发布的许多组件已经提前准备好了，并且没有依赖关系，也必须等待版本中的其他组件。客户想要的功能被延迟，企业失去赢得客户和增加收入的机会。 总体来说，提供方便的基础设施，只是对云计算最初级的利用（提升利用率，按需使用，不够了随时扩容），无法充分发挥云计算的优势，要想充分发挥云计算的优势（弹性、高可用性、易扩展性），就必须进行真正的云化，不仅仅是基础设施和平台的变化，应用也需要做出改变，这就需要摈弃传统的方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点重新设计，从而建设全新的云化的应用，也就是云原生的应用。
云原生的定义
云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。
云原生技术范畴
云原生的技术范畴包括了以下几个方面：
IAAS基础设施即服务，通过internet从计算机基础设施获得服务 （硬件外包）
PAAS平台即服务，提供应用程序开发 （开发分发方案）
SAAS软件即服务，提供完整的应用程序
它们都在试着将各种软、硬件资源等抽象为一种服务提供给开发者使用，让他们不再担心基础设施、资源需求、中间件等等，在减轻心智负担的同时更好地专注于业务。
- 第一部分是云应用定义与开发流程。这包括应用定义与镜像制作、配置 CI/CD、消息和 Streaming 以及数据库等。
- 第二部分是云应用的编排与管理流程。这也是 Kubernetes 比较关注的一部分，包括了应用编排与调度、服务发现治理、远程调用、API 网关以及 Service Mesh。
- 第三部分是监控与可观测性。这部分所强调的是云上应用如何进行监控、日志收集、Tracing 以及在云上如何实现破坏性测试，也就是混沌工程的概念。
- 第四部分就是云原生的底层技术，比如容器运行时、云原生存储技术、云原生网络技术等。
- 第五部分是云原生工具集，在前面的这些核心技术点之上，还有很多配套的生态或者周边的工具需要使用，比如流程自动化与配置管理、容器镜像仓库、云原生安全技术以及云端密码管理等。
- 最后则是 Serverless。Serverless 是一种 PaaS 的特殊形态，它定义了一种更为“极端抽象”的应用编写方式，包含了 FaaS 和 BaaS 这样的概念。而无论是 FaaS 还是 BaaS，其最为典型的特点就是按实际使用计费（Pay as you go），因此 Serverless 计费也是重要的知识和概念。
云原生思想的两个理论
- 不可变基础设施
- 云应用编排理论
云原生关键技术点
当我们回过头来看云原生关键技术点或者说它所依赖的技术理论的时候，可以看到主要有这样的四个方向：
- 如何构建自包含、可定制的应用镜像；
- 能不能实现应用快速部署与隔离能力；
- 应用基础设施创建和销毁的自动化管理；
- 可复制的管控系统和支撑组件。
微服务架构
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。
