1: 什么是云原生

2: 云原生发展

3: 云原生组成

3.1 不可变基础设施

3.2 微服务和服务网格

3.3 容器技术

3.4 DevOps

• DevOps 是 Development 和 Operations 的组合词。它是一组过程、方法与系统的统称，用于促进开发（应用程序 / 软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
• CICD 持续集成 & 持续部署;

3.4.1 代码托管工具

• Gitlab
• Gitee
• Github
• 华为 CodeHub,阿里 Codeup,腾讯 Coding （企业级，收费）

3.4.2 集成流水线工具

• 集成流水线就像传统的工业流水线一样，在经历构建、测试、交付之后，生产出一代一代更新迭代的软件版本。实现了软件产品小步迭代、高频发布、适时集成、稳定的系统演进线路图。在选择集成流水线工具的时候，我们需要关注：
  • 版本控制工具的支持；
  • 每个构建是否可以支持指定多个代码源 URLS；
  • 是否支持构建产物管理库，如公有云对象存储等；
  • 是否支持部署流水线，类似于一个或多个构建完成后触发另一个构建；
  • 是否支持并行构建；
  • 是否支持构建网格，以及对网格内机器管理的能力。如能否将多个构建同时分配到多个构建机器上执行，以提高执行速度；
  • 是否有良好的开放 API，比如触发构建 API、结果查询 API、标准的 Report 接口等；
  • 账户体系，是否支持第三方账户接入，如企业 LDAP 等；
  • 是否有良好的 Dashboard；
  • 多语言支持；
  • 与构建工具（如 Maven，Make，Rake，Nant、Node 等）和测试工具的集成

3.4.3 服务注册发现工具

• 服务发现为 Deploy 的最后环节，缺一不可。无论是四七层负载均衡，还是微服务、RPC 服务框架，服务发现都是产品投产的临门一脚。服务注册发现工具选型需要从生态发展、便利性、语言无关性等角度来综合考量;

3.4.4 持续监控

• 服务的稳定性离不开监控系统的保驾护航。监控系统为服务稳定运行提供数据可视化、异常报警、异常定位、故障追踪等能力；同时监控系统还为服务持续优化升级提供依据和考量标准。

• 监控系统有三大基石：指标、日志、分布式追踪；

• 指标体系：聚焦于故障发现环节，服务以数字形式评估出服务 QPS、成功率、延迟、容量等关键指标，搭配报警系统可以保证当核心指标异常时及时通知开发 / 运维人员。除了核心指标外，服务还可以将各模块 / 阶段的瓶颈点、外部依赖指标量化，建立更加完善服务状态概览，以便服务开发 / 运维人员快速定位异常，完成根因分析。指标系统优势是聚合能力，用较少的存储资源和计算资源表达系统内部状态；

• 日志系统：用于记录服务内发生的各类事件。日志系统聚焦故障定位环节，与指标系统相比，日志系统具有更强的描述性，但也伴随着更大的存储空间和计算存储资源要求。日志是常用的监控方法，比如在具有外部依赖系统的服务中，一般会将外部系统发生的错误和错误原因以日志形式记录下来，以便在故障定位和复盘时恢复异常现场环境。常用方案为 ELK（Elasticsearch、Logstash 和 Kibana ）;

• 分布式追踪系统：用于分析服务调用关系。在微服务盛行的今天，服务之间调用关系越来越复杂，微服务之间相互影响也更加难以定位和排查。分布式追踪系统聚焦于故障定位环节，与指标体系和日志体系不同，分布式追踪系统可以提供服务之间依赖拓扑信息，对于梳理系统调用拓扑、追踪下游依赖导致的异常意义重大。

3.4.5 DevOps 成熟度

DevOps 成熟度是评估效维工具选择的首要参考维度。不同企业 DevOps 发展阶段不一，为了更好地选择适配企业实际情况的效维工具，我们需要从多维度进行评估：

• 组织与文化：DevOps 需要文化与组织的变革，包括研发与运维、IT 与业务之间的隔阂及部门墙的打破。组织支持 DevOps 的力度，以及现阶段文化与 DevOps 的匹配程度是这个维度的关键。
• 敏捷开发：DevOps 是敏捷开发理念的更科学的实践体系，因此前期敏捷做得好不好直接影响到 DevOps 的效果，两者是相辅相成的。
• CI/CD：CI/CD 不仅仅是工具或流程，更是一种方法论，“持续"是其核心。CI/CD 管控从代码提交那一刻到代码运行在生产环境的整个过程。
• 可视化与自动化：可视化是让 DevOps 人性化的重要一环，通过良好的可视化看板，可以快速发现 DevOps 流程中的阻塞点和风险点。自动化一方面是为了更快推动价值流从左向右流动，另一方面也为了将人为失误的风险降到最低。
• 运维监控与预警：开发与运维紧密合作，甚至是一个团队，对于运维的监控和预警对所有相关方可见。
• 持续度量与改进：DevOps 的效果也是需要度量的，“如果你无法度量它，你就无法改进它”。DevOps 提倡更频繁的直面问题，度量则是一种很好的方式帮助我们发现问题，并持续改进。

几乎没有尝试任何 DevOps 实践，或只做了一些基础的 DevOps 工作的企业，适合选取更低门槛甚至是一站式的工具，功能可以比较单一，但主要注重价值流的流转效率。而对于能成熟运用各种 DevOps 实践的企业，适合根据自己的实际需求选取特定环节的组件，并根据团队和组织情况进行修改或定制。