免费域名试用注册网站,网站开发前端工程师,天津网站开发公司电话,中国建造师官方网站查询概述 应用已经跨入了云原生的时代。要写一个时髦的云原生应用#xff0c;首先当然要了解什么是云原生。CNCF#xff0c;也就是云原生计算基金会#xff0c;作为目前人气最旺的云计算行业协会#xff0c;在今年6月份给出了云原生的定义#xff0c;阿里云牵头做了一个官方的…概述 应用已经跨入了云原生的时代。要写一个时髦的云原生应用首先当然要了解什么是云原生。CNCF也就是云原生计算基金会作为目前人气最旺的云计算行业协会在今年6月份给出了云原生的定义阿里云牵头做了一个官方的翻译
“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”
这个定义描绘了云原生应用的几大特点可弹性扩展、容错性好、易于管理和观察、频繁变更同时也列举了支撑这些特点的典型技术手段。下面我们就来聊聊如何用这些技术手段来编写一个云原生应用。 云原生应用之“形” 首先探讨下如何打造一个云原生应用的“形”。
应用分解 第一步是用微服务的架构思想来定义应用的结构。传统的应用经常是一个单体的大雪球随着功能越来越多雪球也越滚越大越来越笨重越来越难以变更终于再也跟不上业务演进的步伐。云原生的一大使命就是要使能业务的快速迭代、试错和创新为此需要把应用分解为多个自包含的、能独立实现、演进和伸缩的个体也就是微服务从而大大提升整个体系的敏捷性。微服务的划分有点像艺术通常的原则是按业务领域来进行划分粒度可大可小一种做法是找出主要的业务对象每个业务对象用一个微服务来实现。以一个网上商店应用为例可以分解为商品、用户、订单等多个微服务如图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网关可以提供简单的编排并实现访问控制、流控、度量、分析等多种能力。
应用部署和管理 第三步就涉及到云原生应用的部署和管理了。容器无疑是现在云原生应用推荐的打包和部署方式其最大的好处就是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的生态目前比较单一。
云原生应用之“神” 有了以上三步打下的基础我们已经有了云原生的“形”了下面我们就来聊聊如何打造云原生的“神”。
可弹性扩展 这要分三个层次来建设。第一层是应用逻辑本身Scale-out的能力这个是基础即每个微服务的应用逻辑部分可以通过横向扩展即部署更多实例来实现更强大的处理能力应用数据和状态的外部化是重要手段这可以借助于公有云上现成的各种云服务来支持例如将数据放到RDS或者NoSQL服务中、将状态放到Redis服务中等。有了这个基础就能进一步实现自动伸缩即应用能根据负载自动地进行缩容或者扩容Kubernetes提供了auto-scaling的能力这样应用的每个微服务就可以独立地进行伸缩。第二层应用管理的能力即随着各个微服务实例的来来去去前端接入层的负载均衡和微服务之间调用的路由要能即时更新这一般借助于云厂商提供的负载均衡服务和微服务调用框架的能力。第三层是应用依赖的云服务自身的弹性能力要能匹配应用规模的变化特别是应用Stateless之后瓶颈就容易转移到数据层此时就要考验云厂商的数据服务的弹性能力了如果无法提供透明的弹性能力应用的弹性能力也就无从谈起。像AWS的Aurora和阿里云的POLARDB这样的云原生数据库提供了更好的弹性能力是面向未来的应用的首选。当然针对业务的特点选用合适的事务模型也很重要。传统上开发人员习惯将所有数据都塞到关系型数据库沿用ACID事务模型编程简单但牺牲了性能和弹性在云原生应用中NoSQL数据库和BASE事务策略则提供了另一个选项很多非交易型的数据例如用户的评价、Tag等完全可以使用这个选项从而获得更好的性能和弹性。
容错性好 这也要从几个层次来建设。第一层从宏观上多AZ甚至多Region的容灾部署和备份早已经是云上应用的最佳实践这样当某个AZ甚至Region发生系统性故障时应用还能继续提供服务。第二层应用的某个微服务或者某个外部依赖发生故障时需要有容错和降级的能力。Netflix在这方面提供了宝贵的经验其开源的Hystrix实现了较完善的熔断和降级能力。第三层个别微服务实例必然会发生故障这就要求它的工作能被别的实例接替而无状态化是重要手段同时负载均衡服务和微服务调用框架需要即时更新路由像Kubernetes这样的管理平台还可以自动创建新的实例以替换掉故障实例。最后“避免故障的最好办法就是经常故障”Netflix倡导的Chaos Engineering无疑给大家开了一个脑洞通过故障演练不断发现系统中的薄弱点验证系统的容错性从而不断加固应用。 易于管理和观察 这部分能力可以通过使用合适的工具和平台获得例如Kubernetes、Dubbo、Istio等提供了很多方便的管理能力特别是后二者可以展示微服务的多项健康指标。现在时髦的人提AIOps在这之前visibility看到应用的状态和automation根据状态自动执行特定操作其实是基础只有这两步做到一定程度积累了足够多的数据和对数据的理解才能去做智能化。 频繁变更 要做到这一点自动化的持续构建和交付能力不可或缺包括多环境验证、灰度发布等。好在主流的云厂商都提供了现成的DevOps工具链作为一个云原生应用最好第一天就是用这些工具来进行构建和发布。 云原生应用的未来
未来其实已经来到了一个是无服务器化一个是AI。
无服务器化Serverless 无服务器化将意味着应用形态的抽象层级会越来越高使得开发者所要操心的事情越来越少。无服务器的容器服务让开发者不用再关心运行容器的资源而无服务器的函数服务则让开发者只需关心片段的代码。从某种意义上讲无服务器化是PaaS的纯粹化而函数计算则更是现阶段PaaS的极致化。函数计算的威力不仅仅在于其轻巧的成本模型更在于其将众多服务编织成一个事件驱动的体系并且让应用逻辑的粒度切分到了极致给应用演进带来了无与伦比的灵活性。当然这种碎片化也给应用的管理带来更大的挑战而我们今天还在与微服务化带来的应用管理和运维的复杂度搏斗。所以在现阶段我的观点是函数计算可以用来实现小型的应用也可以作为大型应用开发中的补充手段但是未来当越来越多的云服务接入事件体系它是有可能会成为主角的特别是很多开发人员已经适应了类似Node.js这样的纯事件驱动的编程模型。
AI AI对于未来应用的重要性已经没有人再怀疑了以至于有人说AI First。那么你的应用需要做些什么呢我的建议是两个关键字场景和数据。首先要识别出AI能给你的业务带来价值的场景这里需要大开脑洞去想以前不敢想的能力去想如果你是神仙你的业务你会作何改变比如假设你能猜到你客户的心思假设你能预测明天发生的事情假设你可以去做某项看似不可能的优化……有了场景再来看可行性有没有数据有没有模型或者算法这其中数据是最重要的。所以要让你的应用多收集数据今天不起眼的数据或许就成为明天的宝藏。比如记录下你应用中的各种用户行为和业务事件这些数据带来的可能性是不可估量的。
总结
云原生应用其实并不难写对吗随着公有云上云原生应用平台越来越完整和强大云原生的各种理念、最佳实践和技术手段都已经内置在其中了比如容器、微服务、服务网格、API等等而函数计算、各种数据分析和AI服务也都日渐成熟。不过应用的本质还是业务的数据模型和处理逻辑这些还是要依赖开发者的人肉智慧云原生只是让开发者能够在
总监课第四期热门产品https://www.aliyun.com/product/ecs?tlogout_aiticai_zongjianke_20181119
阿里云总监系列课重磅上线聚焦人工智能、弹性计算、数据库等热门领域首次集齐12位阿里云技术高管耗时半年精心打磨从理论到实践倾囊相授从零开始绘制技术大牛成长路径限时直播课程免费报名中欢迎戳“http://click.aliyun.com/m/1000011882/”免费报名学习。 原文链接 本文为云栖社区原创内容未经允许不得转载。
