3月25日,网易云技术布道系列第三期·对话架构师活动在网易杭州园区举办,网易云基础服务总经理陈谔、美丽联合集团研发部副总裁曾宪杰和51信用卡CTO郭威分别从云原生应用技术、技术人员的成长和技术对业务的价值等方面带来了干货分享。本文将为大家重点解读网易云基础服务总经理陈谔带来的分享:Cloud Native 实践从0到1。
说到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,而不是让机器规格越变越大。
除了上面提到的基础设施,在项目的工程化方面,陈谔也为大家带来了一些启示。陈谔认为项目工程化是研发协作与云端运维的基础,也是很多团队在起步的时候可能会忽视的事情。项目的整个流程中,开发、测试、发布的每一步都涉及到公司内角色之间的协作,如果这些步骤做得不流畅,每一个环节的衔接非常困难,效率就会变得非常低,所以项目工程化是对高效构建、发布、运行流程的支持。
合理的版本控制工具
项目工程化首先要选择合理的版本控制工具与策略:
常见的版本控制策略包括:
基于配置的依赖管理:
接下来要合理拆分模块,可以按业务拆分模块,同时实现公共代码的模块化。
使用Docker实现环境一致性
之前在网易,对稳定性要求很高的产品,其发布流程通常都很曲折,主要原因在于环境的不一致。陈谔的建议是使用Docker实现环境的一致性,Docker容器完整虚拟化了Linux操作系统,将业务代码与运行环境装箱为Docker容器发布到生产环境,差异仅仅为外部注入的配置(如数据库地址等),容器内部文件在开发环境一旦发布则不再变化,从而保证开发环境与生产环境一致。
工程化是做业务架构,建立一个高效团队的基础,接下来要考虑的就是服务化的思维。微服务是当下很流行的概念,采用微服务确实能为应用的迭代和架构带来很多好处。但服务化的架构会带来额外的负担,如果一个项目还处在初期阶段,网易云的建议则是服务化思维先于服务化架构。
虽然业务初期,不适合服务化,但是应该为后续的服务化做一些准备,否则后面想拆分的时候会变得非常困难:
随着业务的壮大,是否要采用微服务,就要去衡量微服务带来的收益是否大于成本。
收益
成本
降低实施成本
利用基于Kubernetes的基础设施可以简化微服务,一方面Kubernetes提供了基于域名的服务发现:
Kubernetes还可以做基于 iptables的透明RPC 分发:
比如,服务 A访问服务B的虚拟IP VIP,利用 iptables做 DNAT,转成B中的所有成员,服务A可以直接,并利用 probability特性按权重分发请求,比域名做轮转的负载均衡效果要好,因为iptables可控,域名不可控。
用Kubernetes还可以让你获得自动化运维能力:
Kubernetes 以解耦的基础服务层的方式提供了对服务化的支持,避免了代码实现层面的耦合,通过云端托管 Kubernetes 服务能够将实现服务化的成本大幅降低。而且Kubernetes对业务没有侵入性,实现服务化的代价相对会比较小,后面业务变得非常重,需要细粒度控制的时候,再用到其它框架也没有什么影响。
网易云深度整合了Docker技术和Kubernetes集群编排技术,网易云中会有一个Kubernetes Master,所有租户的业务都可以使用这个Master,不用用户自己维护。
前面讲到的都是云原生相关的技术,实际上实现云原生还需要一些研发、运维和组织架构上的方式调整,比如DevOps。DevOps的出现是为了解决运维角色与开发角色的矛盾,运维追求的是可用率优先,而开发希望应用能快速更新迭代。
DevOps 与微服务
微服务架构能够支持更高频的迭代,降低更新迭代的风险,这与 DevOps 的目标是一致;但是微服务架构也会给运维带来成倍的工作量,可基于DevOps分散运维操作,而不是集中依赖少量运维角色。
实施DevOps
实施DevOps需要CI/CD、编排、故障诊断等工具链的支持,同时需要运维实现从操作到审计的职能转换,运维工作前置,在前期和开发团队合作。很多运维还需要开发工具,提高运转效率。
Jenkins-容器-镜像仓库-服务编排
Pipeline as Code:实施服务化后持续集成的复杂度成倍增加,需要定义大量的流程,包含大量Jobs,以代码的方式管理Pipeline能够支持审计,有效管理复杂性并降低维护成本
日志服务-分布式跟踪系统-性能管理服务
最后,陈谔将云原生架构实现的要点总结如下,希望能给云计算的用户带来有价值的参考: