云原生

云时代的基础设施介绍

什么是云基础设施

我理解的基础设施，不只是服务器管理；是各种云（AWS，阿里云，腾讯云等）背后的或者说业务层面以下的各种技术和服务。

• 服务化

• 专业化

• 扩展性

基础设施领域是个高度开源和技术主导的领域；基础设施越强大，业务的扩展性和灵活性越强。越能跳出资源的限制，业务越能从摘取低垂果实去攀登更高的业务价值。基础设施领域任何创新可能会带来业务层的蝴蝶效应。

• 资源云化

  资源集中，规模化共享；想象下业务程序一般是白天比较繁忙，大数据离线计算一般是晚上才大批量运行的；这些资源在时间上错开的，就意味着同一批物理资源是可以共享的。

• 业务云化

  云之前一般是业务去适配或者操作资源，云时代是资源来服务业务。

三驾马车

• 微服务

• 容器 / k8s

• DevOps

Untitled.png

问题来了，

这三者如何表达业务对基础设施的需求？

先上哪个呢？如何上？

还是全部上？

木桶效应？反木桶效应？

微服务

从业务角度来，DDD领域驱动等；这方面技术中心非常厉害。

从资源和底层技术角度来说，微服务比传统SOA或者单体应用有着明显的区别。

传统业务一般只有几个模块，每个模块功能复杂，逻辑全在同一个进程内解决。所以微服务的维护场景主要侧重于单点问题、负载均衡、资源扩容、单个进程状态维护等；像呵护宝宝一样呵护业务进程。

一个系统下，可能会有几百个微服务，这么多的微服务是不可能一个个精心养护的；所以管理这些微服务一定就会有规范和流程；然后根据角色进行关注点分离设计。

运维、平台角度

• 跨环境部署运维

• 服务监控告警

• 服务治理

• 集中化配置管理

• 集中化日志管理

• 微服务接口规范

• 详细调用链跟踪排障

开发者角度

• 代码复用率高

• 需求快速响应

• 性能快速提升

• 数据统一性提升

• 数据访问能力提升

• 数据存储依赖性降低

• 资源利用率提升

Untitled 1.png

举例：单个微服务一般是无状态的，有状态的部分应该被抽离到中间件或者消息队列里面。这样微服务就具备水平扩展能力。

每个进程（微服务）的状态如何被暴露，被周知，被告警之后，实现该进程（服务）的自动化管理。

每个进程的metadata（元信息）的管理；启动命令、运行IP、服务名、关联数据库、关联redis、cpu和memory配置、状态获取方式等等。

容器 / k8s

k8s被称为云操作系统，是基础设施的基础。

容器是什么，最核心的本质对资源进行抽象；然后业务声明式表达资源需求进行匹配。通常情况下，k8s是业界当前对资源利用率的最优解。

k8s要完成对runtime（服务运行时）的管理。生命周期的管理，围绕生命周期的计算、存储、网络，对三者进行抽象和调度，实现自动化管理，并对相关状态、指标进行暴露。

我之前所在的PingCAP是家技术公司（开源分布式数据库）；公司核心产品TiDB数据库是开源的。最初公司想围绕着基础设施做个闭源的商业化管理平台；花费将近半年时间的技术开发；平台越做越像k8s，最后废弃这个项目，开发能力转向k8s。一家初创公司，花费大量人力尝试后转向k8s；到现在k8s开发维持着个庞大团队。

DevOps

说起DevOps，必须要放出下图；资源、业务和管理三者之间的桥梁。要准确的表达出这三者的关系，意味着就是公司组织架构和管理形态映射到DevOps系统里面。

“如果团队、部门、子部门等的组织结构没有紧密反映产品的必要组成或产品组成的关系，那么项目将会遇到麻烦。因此，应该确保组织结构兼容于产品架构。”——《敏捷软件开发的组织模式》

Untitled 2.png

效率和管理的平衡

DevOps不只是一个管理系统，也是个效率系统；

DevOps是以效率前提将各种逻辑（管理逻辑，组织架构形态）显性或隐性嵌入到系统中；然后制定流程规范和工具自动化。这是我认为DevOps核心关键点。

• 流程梳理清楚

• 通过工具把梳理的流程自动化

消息的Hub，交互点

DevOps有Pipeline（流程）的存在，就意味着一定是信息的交互点，各种信息上下文的交换。

信息一般分为两类；metadata信息和状态信息

• metadata信息（元信息）；要准确的描述清楚服务和服务的属性；服务的所属系统、服务启动命令、数据库地址、中间件地址和参数、依赖的上下游、所运行的IP列表、服务状态获取方式等。这个信息一般是记录在CMDB里面，提供API接口给上下游消费。

• 状态信息；基于时间维度表达服务的状态信息，服务的启停时间、是否健康、监控数据、日志关键字等。

如何让信息流动起来

信息收集之后不用起来是没有意义的，如何让信息流转起来，表达出用户和业务需求？

参考GitHub上开源项目，一个优秀的开源项目，来自全世界的人员开发和维护；不同的文化背景，不同的技术层次，不同的目标价值；在同一个项目里面修改代码，并且修改后的代码全世界在使用，是如何做到的信息传达？

云原生

不管基础架构如何变迁，应用架构总是存在，好的应用架构应该是能适应乃至充分利用基础设施的变化，才能保持它的活力和技术竞争力。对于云原生也是相似的，如果没有利用好云的特性，在今天各行业客户都要拓展更广阔市场的前提下，大家都想要异地多活、全球部署的能力，如果还是用老的 IDC 思路去设计应用架构，很难。

面向云原生的应用架构，从某种意义上说，为了获得了更大计算资源、弹性伸缩、自动智能化的可能性，必然会对业务有前置条件和要求。最简单的例子就是 dockerfile，一个标准化的文件可以让软件瞬间分发到几千台服务器，但写过的人都知道，你必须非常克制和准确地表达清晰你的需求，不能像过去一样，基于中心化的基础设施，配置满天飞。所以业界对于面向云原生的软件交付有了"不可变基础设施"这个核心原则，也是现在云原生平台或者系统交付时最核心的理念之一。

必须要提一下CNCF（云原生基金会），我们提的云原生概论是这个组织倡导的；我们用的几乎所有云原生工具或者软件都是在这个组织下孵化、成长起来，然后改变业界的。

CNCF Cloud Native Interactive Landscape

Untitled 3.png

目标是什么

当三驾马车成熟时，我们已经踏入云原生的大门。但是我们一定要明确，我们希望云原生给我们解决什么？

在云原生领域的Serviceless和Service Mesh是用来解决什么痛点、处理什么场景。

• Services Mesh，即服务网格；通过在容器内添加一个代理容器，把业务的网络调用从代码里面抽离出来，通过基础设施来完成。这个代理容器即可以看做基础设施，也可以看做框架。

• Serviceless，即无服务架构；云函数（FaaS)等；业务的逻辑函数和框架分离，框架和基础设施融合；用户的请求先到框架层，框架统一来路由，分配资源。

从“云化”到“云原生化”的这个过程，是企业数字化转型深入过程，需要解决传统应用单体架构厚重、烟囱式架构等带来的一系列应用层面的问题，云对业务的价值不能仅停留在资源供给的阶段。

而是需要让业务能力生于云、长于云，同时基于云构建的新生能力与既有能力有机协同。生于云是指基于云原生的技术、架构和服务来构建企业应用，长于云是指充分利用云的优势来助力企业应用和业务发展，是数字化建设、业务智能升级的基石。