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

Posted 2020-08-18

一、什么是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实现环境一致性

 

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

 

3、服务化的思维

 

工程化是做业务架构，建立一个高效团队的基础，接下来要考虑的就是服务化的思维。微服务是当下很流行的概念，采用微服务确实能为应用的迭代和架构带来很多好处。但服务化的架构会带来额外的负担，如果一个项目还处在初期阶段，我们的建议则是服务化思维先于服务化架构。

 

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

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

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

 

虽然业务初期，不适合服务化，但应该为后续的服务化做一些准备，否则后面想拆分的时候会变得非常困难：

 

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

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

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

• 如果项目发展起来，遇到的第一个问题通常是数据库会挂掉，所以在业务初期就做分库分表是很有必要的；

• 选择事务支持更好的数据库，如果你用缺乏事务支持的数据库做业务的后端，当你要做服务化拆分或分布式事务的时候，可能会比用mysql的痛苦很多。

 

4、实施微服务

 

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

 

 收益

 

• 控制迭代更新的影响域，而单体架构很难评估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，不用用户自己维护。

 

5、DevOps

 

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

 

 DevOps 与微服务

 

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

 

 实施DevOps

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

 

下图是我们内部性能管理的拓扑截图：

 

 

三、总结

 

 

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

 

1. 使用公有云；

2. 重视项目工程化；

3. 项目起步时建立服务化思维，而不要急于采用服务化架构带来不必要的负担；

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

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

原文地址：http://click.aliyun.com/m/21199/