book/xq_study/云原生与微服务.md

云原生与微服务

云原生与微服务是相辅相成的两个东西，微服务的复杂性对运维提出了更高的要求，云原生要达到的运维目标也对应用程序开发有一些要求。

云原生：软件出生就在云上（开发调试的过程中就应该云上，同时也能发现云原生本身对软件的一些要求）

云原生可以定义为一套运行环境，也可被定义为一套软件开发/运维的方法。

• 一套运行环境：Kubernetes作为资源层面标准的；流量治理层面还没有统一的标准（GateWay模式 / SideCar模式）；环境具有高可用，自动化，可观察等特点。
• 一套软件开发/运维的方法：CI/CD，DevOps，用容器抹平环境差异，Kubernetes实现自动化和高可用，流量治理，可观察性的标准（openTelemetry）等。

在云原生环境运行的应用遵循广为传播的[12要素]，（）里面是我想的原因（总之一切为了运维自动化方便，高可用；抹平环境差异，每次人为的修改都应该在自动化的流程内）

• 一份基准代码，多份部署（一个服务应用对应一个git发行版分支，因为这样 CI / CD 方便）
• 显式声明依赖关系（类库，特别是动态库，为了保证开发/测试/生产环境一致， CI / CD 过程顺利）
• 推荐将应用的配置存储于 环境变量（分离可配置部分与静态部分，配置信息方便编排和保存在Kubernetes）
• 应用不会区别对待本地或第三方服务（都是附加资源，可替换，不须修改）
• 严格区分构建，发布，运行这三个步骤（方便做版本发布，测试，回滚等等）
• 应用的进程必须无状态且无共享 。 任何需要持久化的数据都要存储在 后端服务内，比如数据库。（运维时高可用的需求，自动拉起的服务需要无状态；负载均衡也方便等等）
• 应用完全自我加载 而不依赖于任何网络服务器就可以创建一个面向网络的服务。（自完备的独立应用；部署方便；应用服务之间互相调用方便）
• 应用中，进程是一等公民。应用程序必须可以在多台物理机器间跨进程协作工作。（部署实施，扩展资源灵活，容器间协作就是进程间协作）
• 应用的进程是易处理的，意思是说它们可以瞬间开启或停止；进程还应当在面对突然死亡时保持健壮 。 （有利于快速、弹性的伸缩应用，迅速部署，稳健的部署应用）
• 尽可能的保持开发，预发布，线上环境相同（快速，稳定，部署工作可复制性）
• 应用服务不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出（stdout）事件流。（由运行环境统一管理，可观察性的标准）
• 一次性管理进程应该和正常的 常驻进程 使用同样的环境。后台管理代码应该随其他应用程序代码一起发布。（CI / CD 自动化的要求）

微服务应用本身的要求（复杂系统；解决软件退化问题）：

• 人脑的局限性hold不住复杂度太高的东西，认识世界事物就用分层的抽象组合方式，大型软件单体就是扁平化的大堆信息，容易产生软件退化；（面向对象，函数式编程与微服务一样的目的）

• 复杂系统拆分微服务，尽量保持模块边界稳定性，尽力把需求的变化控制在微服务模块内，而不是模块边界。（拆分和规划整体系统，不要敏捷；独立的每个微服务模块开发适合敏捷方式）

• 每个微服务自己独享数据存储，数据由服务完全所有。

• 实现分布式事务。（建议使用Saga模式维护数据一致性；要求等幂性）