.jpg)
.jpg)
.jpg)
.jpg)
一、云原生缘起
云原生的概念为何在近两年突然兴起？
商业模式决定了产品形态，产品决定了研发模式，研发模式又决定了需要采用什么样的技术。
传统应用、互联网应用、VUCA时代的应用，所处的不同时代引发的不同需求，由此带来对技术的不同要求。
以往传统的应用需求是相对固定的，通常以项目化运作，用户的访问量可以预测，容量是有限的，对停开机的要求也没有那么严格；而互联网应用的特征是，需求持续发展，产品化而非项目制（产品与项目的本质区别是什么？留给读者探讨），用户量并非线性往往会有陡增陡降，7x24小时是基本要求；到现在我们经常讲的VUCA时代，商业边界，业务层面是完全不可预知的，即便是对于互联网原住民都是巨大的挑战，要求快速地尝试、快速探测、快速的感知，应用是服务化的方式提供（服务与产品的本质区别又是什么？同样留给读者探讨），业务敏捷性前提之下，对技术体系的持续发布、分布式海量并发、灰度发布和线上测试都是基本诉求。
业务的敏捷性持续发布，应用平台的弹性诉求，商业环境的变化，这是整个云原生产生的时代背景。
二、企业应用架构发展历程
微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上，其特点有：
• 组件化、松耦合、自治、去中心化
• 一组小的服务
• 独立部署运行和扩展
• 独立开发和演化
• 独立团队和自治
企业的应用架构的演化路径，从单体到网状集成，再到ESB的出现，以至微服务架构分布式集成。架构是服务于应用的，而应用是服务于业务的。整体架构的演进过程，就是前面讲到业务环境变化的体现。
三、微服务有高度，采纳需谨慎
Martin Fowler撰文说，You must be this tall to use microservices。
微服务诸多的好处不必强调，但微服务并非包治百病，也并非任何阶段任何团队都应该或者可以采纳的。微服务有高度，采纳需谨慎。
微服务化所带来架构和开发阶段的便利性，其代价是部署时和运行时的管理复杂性极度增加；整体复杂度不变，只是由开发时转为运行时，此外还带来分布式系统的设计和管理的复杂性。
服务拆分解耦的结果，服务可以独立的部署与发布，但运行时服务的治理，包括注册、发现、熔断等，都是需要思考和精心设计的。
此外，微服务的小而自治的团队应该如何管理？多小算小？如何定义自治？在架构的去中心化和分布式趋势下，团队的去中心化管理对传统的管理理念则是巨大的挑战。
四、云原生能力构建
真正做到云原生的成功，我的总结是一个中心三个基本点：
1、 一个中心
以业务的价值交付为中心，达到快速与高效的交付价值，并且在规模化扩展的同时，兼顾可靠性、灵活性等。
2、 三个基本点
1）架构层面
l 采用服务化架构/微服务架构实现全面解耦：把系统划分多个功能内聚、粒度合适、业务边界清晰、独立自治的服务/微服务。以（微）服务为单位演进系统架构，演进式的以绞杀者模式，而不是革命式的一次性改造；单个（微）服务以大于一个的无状态进程运行，实现自身的高可用和 负载均衡 ；把业务数据分布到不同的（微）服务中实现数据的垂直切分；
l 通过API，重用云原生公共服务提供的基础能力和架构能力：内部每个（微）服务须充分利用云原生的公共服务提供底层基础能力，例如微服务管控与生命周期管理服务、 数据库 服务、消息队列服务、缓存服务等；内部每个（微）服务须充分利用应用与 资源编排 服务，实现部署、配置自动化；
l 通过API，打造生态化经济：API是非常重要的方式，除了定义服务之间的业务边界，更重要的是可以通过API的方式做整个生态，数字化转型中比如开放银行，都是这样的思路，搭一个平台，通过各种合作伙伴在不同的行业、不同的领域提供相关的服务，这些服务是相互进行连接，通过链接和网络的思维来去做这个事情。华为云也在打造自己的API生态。
2）工程层面
l 系统与环境、流程、配置解耦：与架构层面解耦相匹配，系统和环境、流程、配置等等需要解耦，工程层面也需要去相应的匹配跟解耦。开发、测试、生产环境等价，屏蔽环境差异性；采纳不可变的基础设施（immutable infrastructure）；
l 构建端到端的DevOps研发体系：研发流程标准化、敏捷化；严格的区分构建、分布、运行的准入准出，并进行版本化和自动化；全自动化测试（单元测试、集成测试、自动生成Mock依赖服务）；一切皆代码，代码、配置与环境严格分离，并进行版本化和自动化；（微）服务持续交付流水线（按需发布版本）；
l 研发运维一体化：运维和开发互相融合，高度协同，共担职责；自动监控，持续可视化反馈，并最终传导到开发团队；按需实时部署、配置热加载实时生效；
l 使用自服务、敏捷的云化基础设施服务：基础设施以自服务的方式对开发团队提供。依赖底层云化基础设施的计算服务、存储服务、网络服务提供基础运行资源；使用 云监控服务 监控自身的运行状态包括基础资源使用状态、自身业务运行状态，同时根据自身运行状态触发相应的运维事件，实现 弹性伸缩 、故障自愈等关键架构特征；
l 核心度量外部指标：业务层面的核心的一个业务指标叫TTM，在DevOps有另外一个词叫Lead Time，就是你的前置时间，从业务需求提出来那一刻起，到这个业务需求上线的时间叫前置时间，这个是可以被客户可知的，所以是端到端的业务指标。技术层面，对应的有多个前置时间，工程这一侧的，则是从提交代码那一刻起，一直到代码上线，这段时间是完全工程可控的，理论上应该是控制在分钟级。这个指标，也是华为云最为看重的一个。
3） 组织层面
l 遵循康威定律：应用的架构和组织架构之间是高度的匹配，单体的应用，逐渐到服务化的方式，到逐渐分布式的模式。组织架构也是转移到自组织，没有一个唯一的中心在里面，自组织团队的敏捷性与多样性需要兼顾。整个团队的规模，典型的就是5-10人规模。
l 全功能团队：从全功能团队一直到云化的运维团队。以服务为单位组织整个团队，涵盖设计、开发、测试、发布、部署、运维全流程职能；开发人员、发布工程师、IT和运维之间可信合作
l 云化运维团队：基于云平台的提供的监控、报警等能力，成立专门的团队负责系统运行时的质量，保障系统可用性和业务无中断的升级、回滚
l 自主经营，面向服务的全生命周期：逐渐转型为自主经营的全功能团队。除了技术栈是全功能以外，每一个服务化的团队都需要面向服务进行全生命周期的考虑，除了技术层面的怎么样去产品的设计、开发出来部署，架构层面保持优美，更多的还需要去考虑商业层面的东西，需要考虑服务定位，考虑产品上线以后，运营层面应该做什么事情，应该做什么样的拉新的活动，怎么样促活，怎么样留存。整个团队都需要有商业思维和产品运营的思维。这是整个思维上的转变，去考虑这个服务为什么这么做、谁去用、用的场景是什么，怎样完成商业的闭环。
五、持续交付实施框架
关注七大领域，持续优化交付粒度，加快交付速度，提升交付质量。
云原生架构与DevOps的落地与转型，需要从团队模型、分支模型、测试模型、技术架构、部署模型、基础设施、数据库模型等七大领域进行相应的匹配。
上图是以发布频度为抓手，从100天发布一次，逐步的十倍速增长，到10天发布一次，在两个阶段点，从七个维度来看，需要匹配与采纳的实践是什么。
所以这是一张能力演进的地图，我们可以清晰的看到自己业务当前所需要的发布节奏是怎样，当十倍速的走到下一个节点，方向在哪里，有的放矢的进行相应的采纳。
与此同时，这也是一个量变到质变的过程，持续优化交付粒度，加快交付速度，提升交付质量。从100天发布1次，到最后的1天发布100次，10000倍的增长，回过头来看，就是一个升维的过程。
六、云原生时代的DevOps体系框架
云原生时代的DevOps体系框架，也需要
l 从商业决策上由基于Gate（Charter/DCP）的业务决策，转变为基于OBP的周期性审视；
l 从服务化组织上，支持E2E全功能团队，开发运维一体化，对团队充分授权；
l 从架构上进行服务化解耦，支持按服务小包独立交付；
l 从开发和运维流程上，加强开发与运维的协同，支持更短的周期，更快的反馈；
l 从IT工具环境上，重用已有的成熟工具，引入先进的开源和商用软件，实现轻量级端到端DevOps工具链；
l 从服务流程上，支持服务的独立交付，自动化的环境部署。
