如何从0到1实践Cloud Native

3月25日，网易云技术布道系列第三期•对话架构师活动在网易杭州园区举办，网易云基础服务总经理陈谔、美丽联合集团研发部副总裁曾宪杰和51信用卡CTO郭威分别从云原生应用技术、技术人员的成长和技术对业务的价值等方面带来了干货分享。本文将为你们重点解读网易云基础服务总经理陈谔带来的分享：Cloud Native 实践从0到1。

陈谔，网易云基础服务总经理，现负责网易云计算平台产品线建设，对内主导公司软件基础设施云化改造，建设网易私有云将网易互联网产品线迁入私有云环境，对外打造公有云产品，实践网易云计算战略。对分布式系统设计开发、云计算平台系统架构有必定的经验和理解。我的同时致力于提高寻求解决方案帮助开发人员提高开发效率，近年来一直带领团队推动公司开发技术栈的标准化、工具化。

什么是Cloud Native？

说到Cloud Native，国内大多数都翻译成云原生，就是让云成为成功的基石，而不是障碍。陈谔对于为何要实现云原生应用深有体会，网易从2012年开始实施云化的战略，当初版云计算平台建好的时候，开始引导公司的项目逐渐向云迁移。这个过程当中就遇到了一个问题：用上云以后，并无变得效率奇高，甚至有些项目的效率反而有所降低，你们有不少抱怨。

从那个时候陈谔就有一个想法，云计算怎样才能成为公司和开发团队成功的基石，而不是用上云以后给你制造麻烦。陈谔认为要作到这一点首先要理解云的优点，规避云的弱点；另外一方面要充分利用云的各层能力，帮助你去成功。因此云原生就是采用适合云端的软件架构和研发模式去作这个事情。

如何实践云原生？

关于如何实践云原生，陈谔为你们分享了一些建议。假设你们不是相似BAT这样规模的公司，或者有很是强大的IT团队，当择技术路线的时候，陈谔建议你们使用公有云，为何呢？

使用公有云

弹性

首先，使用公有云起步的成本很是低，不须要你去租机房、买物理机，每月几百块钱就能够起步了。若是你成功了，在爆发性增加的时候，公有云有足够大的资源弹性来帮助你从一台scale到几百台，不须要临时去买服务器。

网络质量

另外一方面，因为公有云的规模化效应，网络质量是自建不可比拟的：

• 有些公有云出入口的带宽很大，甚至有些互联网大厂的公有云平台，用的基础设施跟公司总体业务是一体的；

• 带宽大的另外一个好处是能够抵御DDoS和CC攻击；

• 其次，公有云有更强的排障能力，国内的国情，网络故障是很是难以排查的，须要有专门的IT团队才能作好。

Managed Cloud Service

云计算有数据库、中间件这些服务，而且不须要你去关注高可用部署、故障恢复、扩缩容等系统层面的运维，操做系统内核级掌控、中间件源码级维护也均由云提供商负责，而且有明确的SLA保障。

高可用保障

另外，云计算能够帮你作高级别的高可用保障。平常的高可用保障，好比双机热备也好，冷备也好，都比不过公有云提供的多可用区的保障。云的多可用区至少是IDC级别的，在一个可用区内就像一张大网同样，至少保证三层的链接，保证你的业务都是互通的，总体架构不用考虑跨机房的问题。

云还有多Region的保障，有一些公司会作异地多活的架构，固然这对业务的侵入性是很大的，但至少能够用多Region的设施，来作数据的灾备。

另外，云的进化速度很快，会持续地更新，如今大多数都是基于Linux的技术栈，可能会不时地出现bug或安全漏洞，若是本身去跟进是很是困难的，公有云通常都会有专业的团队，及时跟进和修复这些安全问题，又省下了用户一笔人员开销。

公有云的取舍

固然，公有云要支持这么大规模的用户，自己有必定的取舍

Design For Failure：公有云倾向于更快失败（影响范围受控）、更快恢复。若是你用的是物理机，出现问题的时候你会关注这个物理机是否是还“活着”。而公有云若是发现一台机器挂了，会直接进行服务迁移和重启，由于公有云自己有SLA的承诺，为了保证系统的鲁棒性，会更快地把这些疑似故障的节点排除掉。

因为公有云这样的特性，平常业务必须结合公有云能力实施高可用架构：

• 一方面以可用域为基础，实现高可用；

• 另外一方面，将数据状态和业务逻辑分离，若是业务被迁移走了，只要挂上原来的盘就能够恢复了；

• 节点可重启或重建

Design For Scale：虚拟化性能稍弱于物理机，公有云更追求交付的性能指标的稳定，避免租户业务间的影响，支持业务作Scale。对于开发者来讲：

• 一方面，要知道你采购的磁盘、网络可以提供的性能是什么，根据这些QoS指标去作容量的规划；

• 另外一方面要基于负载均衡、集群管理等能力去作Scale Out，而不是让机器规格越变越大。

项目工程化

除了上面提到的基础设施，在项目的工程化方面，陈谔也为你们带来了一些启示。陈谔认为项目工程化是研发协做与云端运维的基础，也是不少团队在起步的时候可能会忽视的事情。项目的整个流程中，开发、测试、发布的每一步都涉及到公司内角色之间的协做，若是这些步骤作得不流畅，每个环节的衔接很是困难，效率就会变的很是低，因此项目工程化是对高效构建、发布、运行流程的支持。

合理的版本控制工具

那么如何作到项目的工程化呢？首先要选择合理的版本控制工具与策略：

• Git是社区和业界公认的一个比较好的工具；

• 建议每一个应用采用单一的Codebase（12Factors-1: Codebase），把整个开发，构建，发布的流程串联起来，不至于拉下一个base还要决定这里面的代码哪一部分要拿去构建。

常见的版本控制策略包括：

• 基于Merge的多分支策略，这种模式和多人协做的方式是匹配的，能够看到你们协做产生的代码从分支到合并的过程，可是分支不少也形成了管理的复杂度很高；

• 若是团队能切割得比较小，功能比较集中的话，能够采用基于Rebase的单Master分支策略，它没有Merge信息，管理起来比较简单。

基于配置的依赖管理

而后能够去作基于配置的依赖管理：

• 声明依赖（Maven等），而不是把你的软件包全拷贝在代码库下面，实现自动构建

• 建议声明全部的依赖，包括运行环境的初始化，不隐式依赖系统库（12Factors-2: Dependencies）

接下来要合理拆分模块，能够按业务拆分模块，同时实现公共代码的模块化。

使用Docker实现环境一致性

以前在网易，对稳定性要求很高的产品，其发布流程一般都很曲折，主要缘由在于环境的不一致。陈谔的建议是使用Docker实现环境的一致性，Docker容器完整虚拟化了Linux操做系统，将业务代码与运行环境装箱为Docker容器发布到生产环境，差别仅仅为外部注入的配置（如数据库地址等），容器内部文件在开发环境一旦发布则再也不变化，从而保证开发环境与生产环境一致。

服务化的思惟

工程化是作业务架构，创建一个高效团队的基础，接下来要考虑的就是服务化的思惟。微服务是当下很流行的概念，采用微服务确实能为应用的迭代和架构带来不少好处。但服务化的架构会带来额外的负担，若是一个项目还处在初期阶段，网易云的建议则是服务化思惟先于服务化架构。

• 运维成本：一旦服务多了，环境搭建、故障诊断、运维的工做量都会成倍增长。

• 服务拆分以后，各个服务间的生命周期是不一致的，要作生命周期的分离，就须要处理更多的异常。服务间存在更多的约束，仍是异步的，如依赖关系、版本，要保证消息可以可靠地到达那里；

• 另外一方面，还会有分布式事务的问题，虽然解决起来不难，可是会侵入你的业务

虽然业务初期，不适合服务化，可是应该为后续的服务化作一些准备，不然后面想拆分的时候会变得很是困难：

• 提取Service API，理解业务中的服务抽象

• 数据库设计的时候就考虑服务的划分

• 避免跨服务事务，对跨服务事务进行标记

• 若是项目发展起来，遇到的第一个问题一般是数据库会挂掉，因此在业务初期就作分库分表是颇有必要的

• 选择事务支持更好的数据库，若是你用缺少事务支持的数据库作业务的后端，当你要作服务化拆分或分布式事务的时候，可能会比用MySQL的痛苦不少

实施微服务

随着业务的壮大，是否要采用微服务，就要去衡量微服务带来的收益是否大于成本？

收益

• 控制迭代更新的影响域，而单体架构很难评估patch的影响范围

• 加速迭代，提交代码内心负担小，迭代也能加快

• 隔离局部故障

• 防止代码架构层面的腐化，好比开发过程当中为了赶进度，可能会把原有的架构推倒重来。若是用微服务架构，最多只须要将本身负责的那个模块从新设计。

成本

• 更多的依赖（eg: ZooKeeper，MQ），要作一个注册中心

• 运维复杂度，几十个服务发布更新，运维的复杂度必然会上升，

• 技术实现的侵入性，在这个过程当中不免要用到一些微服务化的框架，虽然对代码的侵入性不大，但对架构的侵入性仍是不可避免的

下降实施成本

• 良好的工程化，不要给运维的工做带来不少困难

• 使用基于云端托管的 PaaS 服务

• 使用基于云端托管的编排服务，帮你去作集群化的运维和管理的工做

基于Kubernetes简化微服务实施

利用基于Kubernetes的基础设施能够简化微服务，一方面Kubernetes提供了基于域名的服务发现

• 使用 VIP+域名暴露服务：对比“注册中心”，采用域名服务具备更小的侵入性，更少的依赖

• 支持名称空间隔离，简化测试环境部署

Kubernetes还能够作基于 iptables的透明RPC 分发

• 无需在程序中访问注册中心获取成员列表进行软负载均衡

• 无需内网负载均衡层次增长网络开销

好比，服务 A 访问服务 B 的 虚拟IP VIP，利用 iptables 作 DNAT，转成B中的全部成员，服务A能够直接，并利用 probability特性按权重分发请求，比域名作轮转的负载均衡效果要好，由于iptables可控，域名不可控。

用Kubernetes还可让你得到自动化运维能力

• 自动扩缩容

• 自动故障处理（重试、迁移）

• 自动化滚动更新，经过健康检查与滚动的配合实现无缝更新

• 还能够基于Service 抽象实现蓝绿发布

Kubernetes 以解耦的基础服务层的方式提供了对服务化的支持，避免了代码实现层面的耦合，经过云端托管 Kubernetes 服务可以将实现服务化的成本大幅下降。并且Kubernetes对业务没有侵入性，实现服务化的代价相对会比较小，后面业务变得很是重，须要细粒度控制的时候，再用到其它框架也没有什么影响。

网易云深度整合了Docker技术和Kubernetes集群编排技术，网易云中会有一个Kubernetes Master，全部租户的业务均可以使用这个Master，不用用户本身维护。

DevOps

前面讲到的都是云原生相关的技术，实际上实现云原生还须要一些研发、运维和组织架构上的方式调整，好比DevOps。DevOps的出现是为了解决运维角色与开发角色的矛盾，运维追求的是可用率优先，而开发但愿应用能快速更新迭代。

DevOps 与微服务

微服务架构可以支持更高频的迭代，下降更新迭代的风险，这与 DevOps 的目标是一致；可是微服务架构也会给运维带来成倍的工做量，可基于DevOps分散运维操做，而不是集中依赖少许运维角色。

实施DevOps

实施DevOps须要CI/CD、编排、故障诊断等工具链的支持，同时须要运维实现从操做到审计的职能转换，运维工做前置，在前期和开发团队合做。不少运维还须要开发工具，提升运转效率。

基于DevOps工具链支持微服务架构

Jenkins-容器-镜像仓库-服务编排

Pipeline as Code：实施服务化后持续集成的复杂度成倍增长，须要定义大量的流程，包含大量Jobs，以代码的方式管理Pipeline可以支持审计，有效管理复杂性并下降维护成本

日志服务-分布式跟踪系统-性能管理服务

• 日志服务：Kafka+ELK套件，以网易云为例自动完成容器日志收集，并提供订阅接口可对接ELK。

• 分布式跟踪系统：在微服务架构下必需要作到与单体架构一样的服务请求的调用路径跟踪能力，才可以有效定位故障。可参考的框架有Zipkin, 须要对RPC框架等作instrumentation，在调用过程当中携带额外的头信息。

• 性能管理服务：微服务架构下依赖关系复杂，发生性能问题时难以定位源头及影响范围，性能管理服务可提供调用关系拓扑，及时统计慢响应及错误响应，有利于发现性能问题与定位故障。以网易云为例，利用Kubernetes提供元信息，利用AOP对经常使用库作instrumentation，可在无须配置及侵入代码的状况下，自动绘制拓扑，分析性能。下图是网易云内部性能管理的拓扑截图：

总结

最后，陈谔将云原生架构实现的要点总结以下，但愿能给云计算的用户带来有价值的参考：

• 使用公有云

• 重视项目工程化

• 项目起步时创建服务化思惟，而不要急于采用服务化架构带来没必要要的负担

• 实施微服务需权衡收益与成本，基于Kubernetes可简化微服务实施

• DevOps能与微服务架构良好匹配，但实施DevOps须要完善的工具链支持