大家好!很高兴今天又有机会和大家一起聊云原生。
过去的十年,毫无疑问是云计算的十年,我是在2009年加入微软的Azure平台开始做云,当时云计算还是个很玄乎的概念,有人觉得跟大气层有关。到了今天2019年,正如当时预期的,云变成人们习以为常的东西,就像水和电一样。人们不再满足于上云,更关注如何最大化释放云计算的全部生产力,这就是我们今天要讨论的云原生。
如果用一句话概括2019年,我觉得这句最合适:2019年是云原生理念和技术普及的元年,就是说在很近的将来,云原生也会变成一个新的常态。
今天主要想跟大家聊两个话题,一是云原生基础设施领域有哪些值得关注和正在发生的事情和趋势,一个是云原生的应用架构在企业IT如何落地。
讨论云原生基础设施,要先回到Kubernetes,Kubernetes已经是主流,这点毫无争议。从去年年底,我们就开始说Kubernetes正在变得boring。这有几层意思:
第一,核心的技术变更开始变慢,这是向好的迹象,它一方面表明技术已经成熟,另一方面它的定位和边界非常清晰,哪些东西放在核心里面,哪些东西通过扩展去做非常明确。另外,创新仍在持续,但创新会转移到技术栈的更上层。第三,Kubernetes会变得无处不在,人们会对它习以为常。
Kubernetes核心社区主要致力于三个主要目标:
第一,持续提升核心技术栈的稳定性、易用性、可扩展性。
第二,将更多的技术集成到以 Kubernetes 为核心的 “云原生技术栈”。
第三,将“云原生技术栈” 扩展到更广泛的应用场景。
Kubernetes编排一切
不久前微信上流行一篇文章,叫“Kubernetes编排一切”。Kubernetes的核心是声明式API,以及基于“控制器”模型的架构设计范式。容器编排只是这种架构的一种应用,基于它的一些扩展机制,如CRD+Custom Controller,可以把这种架构应用到对任意资源的编排。数据中心的所有工作负载以及数据中心之外边缘计算等场景都可以用Kubernetes编排。
理论上,所有可编程,有API,可抽象成资源的对象,都可以通过Kubernetes去编排。换个角度,Kubernetes可以理解成一个开发框架,基于这个框架可以去构建各式各样的上层平台。
ACP 2.0重大升级,完全基于Kubernetes原生架构
今年6月底,灵雀云发布了一站式云原生应用赋能平台Alauda Container platform (ACP)2.0的重大升级。这次升级是技术架构的重大升级,产品架构完全转成Kubernetes原生架构。原来产品所有功能都迁移到新的架构上,同时把DevOps(Alauda DevOps)平台和Service Mesh(ASM)在集群和多租户平台上对齐,三个产品融合到Kubernetes原生的架构下面。
更广泛采用 Operators 实现自动化运维
Operators是更广泛采用的技术和模式。基于Kubernetes 扩展机制,将运维知识编写成 “面向应用的 Kubernetes 原生控制器”,从而将一个应用的整体状态作为 API 对象通过 Kubernetes 进行自动化管理。
主要有两大应用场景:复杂的分布式、有状态应用的自动化运维,和基础设施本身(包括 Kubernetes)的自动化运维。
在ACP的后续版本中,我们会持续引入更多的Operators,一方面是通过Operators来实现平台自身的自动化部署、运维和升级。另一方面,让客户便捷地使用一些社区和其他厂商提供的成熟的Operators。
到底什么才是Kubernetes应用?经常有人吐槽Kubernetes里并没有一个叫应用的资源。我们认为在Kubernetes这一层,至少在底层不去定义应用的概念和资源是正确的,甚至是高明的。它定义的是更加灵活的机制,基于底层抽象和扩展机制,在上面定义各种适合的资源,最后形成一系列Patterns,最后达到的效果是上层可以去定义任意种类的丰富的工作负载。如果直接在Kubernetes这一层去定义一个应用和资源的话,恐怕很难做到。
混合云和多云部署将成为常态
混合云和多云部署将成为常态,这点可能是云原生技术对公有云的厂商一个最直接的影响。Kubernetes成为云操作系统,它是第一个真正意义上的操作系统,对底层基础设施提供统一抽象。
还有一些技术会让跨云部署往前推进。KubeFed集群跨云联邦与应用跨云部署、Open Service Broker API为深度集成云厂商 Backing Services 提供统一的抽象。
整个云原生领域的创新仍在持续,这种创新开始转移到技术栈的上层。我们会慢慢看到从这些技术当中沉淀出一个核心的云原生技术栈,底层是Kubernetes,中间是ServiceMesh,往上是Serverless。从Kubernetes开始,我们不断做的事情就是把应用里面和业务不相关的东西剥离出来,放到基础设施里。Kubernetes解决的是部署管理的问题。ServiceMesh解决应用层面、网络连接相关的问题。Severless把整个运行时都做了虚拟化、抽象。
接下来我们聊一下云原生的应用架构,尤其是云原生应用架构在企业IT环境里面的落地。
在数字化转型的压力下,企业面临着严峻的应用架构挑战,诸如现代化用户体验与业务敏捷性的矛盾,单体架构遗留的技术债,有限资源与业务持续性的矛盾,整个企业的IT架构不可能一蹴而就全部变成云原生。
我们从两方面来看,首先云原生的应用架构应该什么样。其次,云原生应用架构在企业IT环境里怎么落地。
微服务落地需要一套完整的基础设施
微服务架构本质上是以运维的复杂度为代价去换取敏捷性,这时候要考虑企业是否真的有敏捷性需求,如果答案是否定的,就不要引入更多的复杂度。如果答案是肯定的,需要引入复杂度,那么如何管理多出来的复杂度,就是我们一直讨论微服务治理的原因。微服务治理不只是Service Mesh或者Spring Cloud,它需要一个完整的基础设施去支撑。
微服务最大的挑战是会引入运维的复杂度,所以自动化运维非常重要,尤其是可观测性。在微服务后面需要各种后端数据服务,如何管理后端的数据服务,把这些服务暴露给应用,是要考虑的问题。
最后,聚焦到微服务内部,服务和服务之间的连接和通讯治理,这是狭义上的微服务治理。这个问题的解决方案现在有一个很时髦的名词叫Service Mesh。微服务治理意味着进入到后Kubernetes时代。早期微服务作为一个需求、一个用例在推动容器和Kubernetes的发展,当Kubernetes变成标准之后,它会反过来驱动,重新定义微服务治理的最佳实践。
今天有一个共识,如果基于Kubernetes平台做微服务治理,ServiceMesh是最佳实践。
6月底,灵雀云重大升级的ACP2.0里有一个子产品是ASM(AlaudaService Mesh),它是一个企业级的服务网格和微服务治理平台。ASM主要关注五大重要的场景:第一服务全局可观测性,包括非常细致的服务拓扑和端到端的调用链。第二服务发布管理,包括灰度发布、AB测试、蓝绿切换等。第三服务连接可靠性治理,如熔断降级、限流等。第四是服务安全性治理。第五是服务网格全生命周期管理。
云原生应用架构如何在企业落地?
那么如上所述的云原生应用架构在企业IT环境如何落地?尤其是很多企业的IT系统经过了长时间积累,复杂臃肿,没有人敢去改动它,牵一发而动全身,而且有些还是企业的核心业务系统。云原生应用架构要在企业IT环境落地,必须务实。
有几大需要遵循的原则:第一,并不是所有应用都需要做微服务的拆分,做微服务化,多种粒度的服务同时并存,是很正常的事情,甚至可以反过来考虑这件事情,默认的、缺省的应该从比较大的粒度开始,当真正有业务层面敏捷性需求时,再按照变更的边界和优先级去逐步做微服务的拆分。
第二,当有敏捷性需求,一定要意识到微服务化之后会带来运维的复杂度,所以做了微服务化一定要拥抱云原生,将微服务应用迁移到Kubernetes平台上,甚至在Kubernetes平台上应该用Service Mesh对它做微服务治理。
第三,API在整个架构中起到非常重要的作用,一个应用即便不做微服务拆分、不改动技术架构,也可以做一些服务化的适配,把关键能力通过API暴露出来。通过 API 来实现内部集成和对外能力开放。
第四,需要做API治理,API治理一般通过API网关来实现,但可能不会只有一个API网关,可能有多个层级的API网关。一般来说,越往上,API网关的职能越偏向运营,越往下,API网关的职能越偏向技术。
在传统企业落地云原生应用架构的实践中,API和API治理至关重要。灵雀云近期推出了API层面的新产品——企业级API管理平台Alauda API Management platform(AMP),它的定位是企业总的API网关,主要负责南北向的API治理,更偏运营,主要职责是API全生命周期管理、API能力开放运营(API Economy)、API治理。
最后忍不住放一张大鱼吃小鱼的图。Marc Andreessen 2011年说,“软件正在吞噬世界”,这句话被无数人反复说起。现在开源软件变成软件交付的一种主要形式,也可能变成软件标准制定的唯一方式。云计算变成了主流,公有云甚至变成了主流。最近一两年,人们开始讨论云原生,一定程度上,可以把云原生看作是云计算领域的开源运动。
登录后评论
立即登录 注册