这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
云计算
IaaS 基础架构即服务（或 IaaS）让您从本地基础架构往轻松迈进了一步。这是一种即付即用的服务，由外部的第三方提供商根据您的需要，利用互联网（通过云）为您提供基础架构服务（如存储和虚拟化）。
作为用户，您只需负责操作系统以及任何数据、应用、中间件和运行时，而提供商会给您访问和管理所需网络、服务器、虚拟化和存储的权限。
PaaS
平台即服务（PaaS）与全面本地基础架构的区别又更拉大了一些。在该方案下，提供商将硬件和软件托管在自己的基础架构上，并通过互联网连接以集成解决方案、解决方案堆栈或服务的形式将该平台交付给用户。
PaaS 主要面向开发人员和程序员，它允许用户开发、运行和管理自己的应用，而无需构建和维护通常与该流程相关联的基础架构。
SaaS 软件即服务（SaaS）也称为云应用服务，是最全面的云计算服务，它通过 Web 浏览器交付由提供商管理的整个应用。
提供商将负责处理软件更新、漏洞修复及其他常规软件维护工作，而用户则通过控制面板或 API 连接至应用。它不需要在每台计算机上安装软件，而且对程序的组访问更加流畅可靠。
举例来说，如果您有一个基于 Web 的服务（例如 Outlook 或 Gmail）的电子邮件帐户，那么您就早已对 SaaS 不陌生了，您可以从任意位置、通过任何计算机来登录帐户并收取电子邮件。
FaaS 类似leetcode 的在线服务
云原生
云原生没有确定的概念，每个人和组织对于云原生的定义是不一样的，即使相同的人在不同的时间对于云原生定义都是变化的。从而可以确认的是云原生是持续发展的，技术是持续进步的。 不过有几点可以确定的是：
- 云原生的应用在开始设计的时候应该重复考虑其云化：分布式、微服务化、容器化、云化部署、持续迭代等特点。
- 重复利用云带来的api、工具、组件（Iaas、Paas、SaaS）等，让应用建设更高效（native的一种解释）
技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。 云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
云原生的四要素：
微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，很玄乎，凡是能称为理论定律的都简单明白不了，不然就忒没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无关系。
微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。
容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌搞的，Docker和K8S都采用Go编写，都是好东西。
DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。
持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。
概括来讲：
云原生的定义： 技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，
云原生的四个要点：云原生既然是一套方法论那么就会有自己的主要特点 DevOps+服务网格+微服务架构+弹性资源
弹性资源： 虚拟化容器 快速扩缩容 用户不需要感知底层的资源生态
微服务架构 松耦合 提升可能性
DevOps CI/CD 敏捷开发 持续开发提交部署
服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。
如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无需关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关心服务之间的那些原本通过服务框架实现的事情，比如 Spring Cloud、Netflix OSS 和其他中间件，现在只要交给 Service Mesh 就可以了。
参考资料
码风略丑 读者见谅 --2023/2/13
