【阿里云总监课第四期】时髦的云原生应用怎么写？

概述
应用已经跨入了云原生的时代。要写一个时髦的云原生应用，首先固然要了解什么是云原生。CNCF，也就是云原生计算基金会，做为目前人气最旺的云计算行业协会，在今年6月份给出了云原生的定义，阿里云牵头作了一个官方的翻译：

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的表明技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术可以构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师可以轻松地对系统做出频繁和可预测的重大变动。”

这个定义描绘了云原生应用的几大特色：可弹性扩展、容错性好、易于管理和观察、频繁变动，同时也列举了支撑这些特色的典型技术手段。下面咱们就来聊聊如何用这些技术手段来编写一个云原生应用。
云原生应用之“形”
首先探讨下如何打造一个云原生应用的“形”。

应用分解
第一步，是用微服务的架构思想来定义应用的结构。传统的应用常常是一个单体的大雪球，随着功能愈来愈多，雪球也越滚越大，愈来愈笨重，愈来愈难以变动，终于再也跟不上业务演进的步伐。云原生的一大使命就是要使能业务的快速迭代、试错和创新，为此须要把应用分解为多个自包含的、能独立实现、演进和伸缩的个体，也就是微服务，从而大大提高整个体系的敏捷性。微服务的划分有点像艺术，一般的原则是按业务领域来进行划分，粒度可大可小，一种作法是找出主要的业务对象，每一个业务对象用一个微服务来实现。以一个网上商店应用为例，能够分解为商品、用户、订单等多个微服务，如图1。

图1

应用开发
第二步，天然是定义和编写每一个微服务。定义微服务最重要的是定义其暴露的API，能够是HTTP协议的API例如REST风格的，也能够是RPC协议的。HTTP路线的好处是其被普遍接受和使用，放之四海而皆准（标准成熟完备、各类编程语言全都支持、各类编程框架和生态健全）、网络畅通无阻（负载均衡、防火墙、缓存优化等配套包罗万象），坏处是封装级别较高致使整链路overhead较多、性能较差；而RPC路线例如Thrift、Dubbo等性能和时延要好不少，虽然也能作到跨语言，但缺点是其并不是普遍接受的标准。gRPC基于HTTP 2.0，算是两种路线的折衷。

在之前，选用哪一种协议一般与你选择哪一种微服务调用框架紧密相关。例如若采用HTTP路线，则能够考虑使用Netflix开源的一系列组件做为微服务的调用框架，包括Eureka、Ribbon、Zuul等，Spring作了很好的集成，融合到其Spring Boot体系中，对Java开发者是个不错的选择；若采用RPC路线，那么Dubbo完整的运行和管理体系也让其成为一个很好的选项，近年来其对多语言的支持也逐渐丰富。而服务网格（Service Mesh）技术的出现，使得微服务的数据面和管理面清晰解耦，从而让多协议支持和各类管理能力的插入更加容易；更重要的是，sidecar的方式让应用与微服务的管理体系独立运行，大大减小了对应用的侵入性。Istio是当下比较流行的服务网格实现，支持HTTP、gRPC、TCP等协议，Dubbo协议也在积极接入到Istio中。

微服务的API主要是面向内部即微服务之间的交互，而做为一个云上的原住民应用，还须要一个对外的公共API，不然就没法跟云上的其余应用和端上的各类设备灵活地沟通。这层API一般使用API网关来进行管理和暴露，对接到后端的微服务的API。API网关能够提供简单的编排，并实现访问控制、流控、度量、分析等多种能力。

图2

应用部署和管理
第三步，就涉及到云原生应用的部署和管理了。容器无疑是如今云原生应用推荐的打包和部署方式，其最大的好处就是portability，不只让开发环境和部署环境更加一致，并且能让应用更容易地在私有云、不一样vendor的公有云之间迁移。每一个微服务能够打包成一个或多个容器来进行部署。虽然你可使用docker等较原子的工具来进行部署，但因为一个云原生应用一般包含数量较多的容器，采用Kubernetes等容器编排工具来对这些容器进行部署和管理会省事不少。同时，Kubernetes也经过Secrets和ConfigMaps支持配置外部化，这也是云原生的最佳实践之一，以遵循Immutable application的原则。主流的云厂商都提供了Serverless Kuberbetes服务，即用户无需管理运行容器所需的计算节点，只管按Kubernetes的规范来描述应用而后“一键”部署就好，资源按需使用，向着云原生的体验又进了一步。Cloud Foundry尝试的路径更加激进，它但愿给开发者一个纯粹的以应用为中心的体验，只要推送代码，Cloud Foundry就会调用对应的buildpack来进行应用的打包最后以容器的方式来进行部署。这种方式比较适合拓补和依赖相对简单的应用特别是Web应用，所谓有得必有失，Cloud Foundry给了开发者更多便利，同时也限制了开发者对环境的控制和对应用的底层管理的能力。OpenShift试图为Kubernetes体系引入相似于Cloud Foundry的部署体验但同时保留开发者在Kubernetes层的控制能力，不过OpenShift的生态目前比较单一。

图3

云原生应用之“神”
有了以上三步打下的基础，咱们已经有了云原生的“形”了，下面咱们就来聊聊如何打造云原生的“神”。

可弹性扩展
这要分三个层次来建设。第一层是应用逻辑自己Scale-out的能力，这个是基础，即每一个微服务的应用逻辑部分能够经过横向扩展（即部署更多实例）来实现更强大的处理能力，应用数据和状态的外部化是重要手段，这能够借助于公有云上现成的各类云服务来支持，例如将数据放到RDS或者NoSQL服务中、将状态放到Redis服务中等。有了这个基础，就能进一步实现自动伸缩，即应用能根据负载自动地进行缩容或者扩容，Kubernetes提供了auto-scaling的能力，这样应用的每一个微服务就能够独立地进行伸缩。第二层，应用管理的能力，即随着各个微服务实例的来来去去，前端接入层的负载均衡和微服务之间调用的路由要能即时更新，这通常借助于云厂商提供的负载均衡服务和微服务调用框架的能力。第三层，是应用依赖的云服务自身的弹性能力，要能匹配应用规模的变化，特别是应用Stateless以后，瓶颈就容易转移到数据层，此时就要考验云厂商的数据服务的弹性能力了，若是没法提供透明的弹性能力，应用的弹性能力也就无从谈起。像AWS的Aurora和阿里云的POLARDB这样的云原生数据库提供了更好的弹性能力，是面向将来的应用的首选。固然，针对业务的特色选用合适的事务模型也很重要。传统上开发人员习惯将全部数据都塞到关系型数据库，沿用ACID事务模型，编程简单但牺牲了性能和弹性；在云原生应用中，NoSQL数据库和BASE事务策略则提供了另外一个选项，不少非交易型的数据（例如用户的评价、Tag等）彻底可使用这个选项，从而得到更好的性能和弹性。

图4

容错性好
这也要从几个层次来建设。第一层，从宏观上，多AZ甚至多Region的容灾部署和备份早已是云上应用的最佳实践，这样当某个AZ甚至Region发生系统性故障时，应用还能继续提供服务。第二层，应用的某个微服务或者某个外部依赖发生故障时，须要有容错和降级的能力。Netflix在这方面提供了宝贵的经验，其开源的Hystrix实现了较完善的熔断和降级能力。第三层，个别微服务实例必然会发生故障，这就要求它的工做能被别的实例接替，而无状态化是重要手段；同时，负载均衡服务和微服务调用框架须要即时更新路由；像Kubernetes这样的管理平台还能够自动建立新的实例以替换掉故障实例。最后，“避免故障的最好办法就是常常故障”，Netflix倡导的Chaos Engineering无疑给你们开了一个脑洞，经过故障演练，不断发现系统中的薄弱点，验证系统的容错性，从而不断加固应用。

图5

易于管理和观察
这部分能力能够经过使用合适的工具和平台得到，例如Kubernetes、Dubbo、Istio等提供了不少方便的管理能力，特别是后两者，能够展现微服务的多项健康指标。如今时髦的人提AIOps，在这以前，visibility（看到应用的状态）和automation（根据状态自动执行特定操做）实际上是基础；只有这两步作到必定程度，积累了足够多的数据和对数据的理解，才能去作智能化。

图6

频繁变动
要作到这一点，自动化的持续构建和交付能力不可或缺，包括多环境验证、灰度发布等。好在主流的云厂商都提供了现成的DevOps工具链，做为一个云原生应用，最好第一天就是用这些工具来进行构建和发布。

图7

云原生应用的将来

将来其实已经来到了，一个是无服务器化，一个是AI。

无服务器化（Serverless）
无服务器化将意味着应用形态的抽象层级会愈来愈高，使得开发者所要操心的事情愈来愈少。无服务器的容器服务让开发者不用再关心运行容器的资源，而无服务器的函数服务则让开发者只需关心片断的代码。从某种意义上讲，无服务器化是PaaS的纯粹化，而函数计算则更是现阶段PaaS的极致化。函数计算的威力不只仅在于其轻巧的成本模型，更在于其将众多服务编织成一个事件驱动的体系，而且让应用逻辑的粒度切分到了极致，给应用演进带来了无与伦比的灵活性。固然，这种碎片化也给应用的管理带来更大的挑战，而咱们今天还在与微服务化带来的应用管理和运维的复杂度搏斗。因此在现阶段，个人观点是函数计算能够用来实现小型的应用，也能够做为大型应用开发中的补充手段；可是将来，当愈来愈多的云服务接入事件体系，它是有可能会成为主角的，特别是不少开发人员已经适应了相似Node.js这样的纯事件驱动的编程模型。

图8

AI
AI对于将来应用的重要性已经没有人再怀疑了，以致于有人说AI First。那么你的应用须要作些什么呢？个人建议是两个关键字：场景和数据。首先要识别出AI能给你的业务带来价值的场景，这里须要大开脑洞，去想之前不敢想的能力，去想若是你是神仙，你的业务你会做何改变？好比假设你能猜到你客户的心思，假设你能预测明天发生的事情，假设你能够去作某项看似不可能的优化……有了场景，再来看可行性：有没有数据？有没有模型或者算法？这其中，数据是最重要的。因此，要让你的应用多收集数据，今天不起眼的数据或许就成为明天的宝藏。好比，记录下你应用中的各类用户行为和业务事件，这些数据带来的可能性是不可估量的。

图9

总结

云原生应用其实并不难写，对吗？随着公有云上云原生应用平台愈来愈完整和强大，云原生的各类理念、最佳实践和技术手段都已经内置在其中了，好比容器、微服务、服务网格、API等等，而函数计算、各类数据分析和AI服务也都日渐成熟。

总监课第四期热门产品：https://www.aliyun.com/product/ecs?tlog=out_aiticai_zongjianke_20181119

原文连接