当红架构Cloud Native，怎么搭建才能成为上云助攻手？

《当红架构Cloud Native，怎么搭建才能成为上云助攻手？》要点：
本文介绍了当红架构Cloud Native，怎么搭建才能成为上云助攻手？，希望对您有用。如果有疑问，可以联系我们。

作者：陈谔,网易云基础服务总经理,现负责网易云计算平台产品线建设,对分布式系统设计开发、云计算平台系统架构有一定的经验和理解.近年来致力于带领团队推进公司开发技术栈的标准化、工具化.

网易云基础服务团队：网易云基础服务拥有优质的硬件资源,经验丰富的研发运维团队,为各类客户提供IaaS、PaaS服务.同时深度整合Docker与Kubernetes技术,打造专业的容器服务.

如何让云成为业务成功的基石而不是障碍,是技术团队需要不断思考的问题,Cloud-Native正是一种让业务技术架构向云而生,充分利用云特性的技术理念与方法论.在近期网易云技术布道系列活动中,网易云基础服务总经理陈谔带来了如何从0到1实践Cloud-Native的精彩分享.

一、什么是Cloud Native?

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

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

二、如何实践云原生?

关于如何实践云原生,陈谔为大家分享了一些建议.假设大家不是类似BAT这样规模的公司,或者有非常强大的IT团队,在选择技术路线时,陈谔建议大家使用公有云,为什么呢?

1、使用公有云

弹性

首先,使用公有云起步的成本非常低,不需要你去租机房、买物理机,每个月几百块钱就可以起步了.如果你成功了,在爆发性增长时,公有云也有足够大的资源弹性帮助你从一台Scale到几百台,而不需要临时去买服务器.

网络质量

另一方面,由于公有云的规模化效应,网络质量是自建不可比拟的：

有些公有云出入口的带宽很大,甚至有些互联网大厂的公有云平台,用的基础设施跟公司整体业务是一体的；
带宽大的另一个好处是可以抵御DDoS和CC攻击；
其次,公有云有更强的排障能力.国内的国情,网络故障是非常难以排查的,需要有专门的IT团队才能做好.

Managed Cloud Service

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

高可用保障

此外,云计算可以帮你做高级别的高可用保障.日常的高可用保障,比如双机热备也好,冷备也好,都比不过公有云提供的多可用区的保障.云的多可用区至少是IDC级别的,在一个可用区内就像一张大网一样,至少保证三层的连接,保证你的业务都是互通的,整体架构不用考虑跨机房的问题.

云还有多Region的保障,有一些公司会做异地多活的架构,当然这对业务的侵入性是很大的,但至少可以用多Region的设施,来做数据的灾备.

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

公有云的取舍

当然,公有云要支持这么大规模的用户,本身有一定的取舍.

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

2)由于公有云这样的特性,日常业务必须结合公有云能力实施高可用架构：

• 一方面以可用域为基础,实现高可用；
• 另一方面,将数据状态和业务逻辑分离,如果业务被迁移走了,只要挂上原来的盘就可以恢复了；
• 节点可重启或重建.

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

• 一方面,要知道你采购的磁盘、网络能够提供的性能是什么,根据这些QoS指标去做容量的规划；
• 另一方面要基于负载均衡、集群管理等能力去做Scale Out,而不是让机器规格越变越大.

2、项目工程化

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

合理的版本控制工具

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

• Git是社区和业界公认的一个比较好的工具；
• 建议每个应用采用单一的Codebase(12Factors-1: Codebase),把整个开发,构建,发布的流程串联起来,不至于拉下一个base还要决定这里面的代码哪一部分要拿去构建.

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

• 基于Merge的多分支策略,这种模式和多人协作的方式是匹配的,可以看到大家协作产生的代码从分支到合并的过程,但是分支很多也造成了管理的复杂度很高；
• 如果团队能切割得比较小,功能比较集中的话,可以采用基于Rebase的单Master分支策略,它没有Merge信息,管理起来比较简单.

基于配置的依赖管理

然后可以去做基于配置的依赖管理：

声明依赖(Maven等),而不是把你的软件包全拷贝在代码库下面,实现自动构建
建议声明所有的依赖,包括运行环境的初始化,不隐式依赖系统库(12Factors-2: Dependencies)

接下来要合理拆分模块,可以按业务拆分模块,同时实现公共代码的模块化.

使用Docker实现环境一致性

（编辑：ASP站长网）