应用如何快速实现云原生化?华为云DTSE解读关键策略
摘要:从代码到架构的梳理规划,华为云DTSE在短短2个月的时间就帮助企业开发者完成了初步的应用云原生化。 本文分享自华为云社区《DTSE Tech Talk | 第64期:DTSE与开发者同行,探索云原生实践,共筑高效云优化之路》,作者:华为云社区精选。 在主题为《DTSE与您同行,探索云原生实践,共筑高效云优化之路》的直播活动中,华为云云原生DTSE技术布道师王逸真,与开发者们交流云原生的核心优
摘要:从代码到架构的梳理规划,华为云DTSE在短短2个月的时间就帮助企业开发者完成了初步的应用云原生化。
本文分享自华为云社区《DTSE Tech Talk | 第64期:DTSE与开发者同行,探索云原生实践,共筑高效云优化之路》,作者:华为云社区精选。
在主题为《DTSE与您同行,探索云原生实践,共筑高效云优化之路》的直播活动中,华为云云原生DTSE技术布道师王逸真,与开发者们交流云原生的核心优势和关键技术,从解读企业应用云原生的“三阶段两转变”到开发者技术支持工程师(DTSE)为开发者提供全流程技术支持,并向大家剖析了客户实例,揭秘探索云原生实践,解决客户痛点。
云原生已成为企业IT基础设施主流选择
云原生已经成为企业IT基础设施的主流选择,据行业机构的调研结果,在2023年,全球容器的数量已经超过虚拟机数量,且后续两者的差距会越来越大。目前,全球各行业约80%的应用完成了云原生化改造。
云原生给企业带来的价值
从整体架构上看,企业应用云原生化可以让企业从垂直烟筒式的技术平台变成敏捷高性能开放的云原生基础设施,从多机房割裂式的资源池变成统一,标准云原生混合云架构。
从具体场景来看,云原生技术在对资源利用效率、对业务弹性的价值最为明显,随着云原生技术在各行业的普及,不同行业对云原生应用的核心诉求存在一定差异,相对而言,资源利用率,弹性与多云是核心诉求和技术价值。
如何选择云原生技术厂家?
华为云在2017年就成为CNCF初创会员,是容器标准的制定者,在随后更是不断地发展云原生技术,落地云原生实践,目前已经成为云原生产业发展的先行领导者。
企业应用云原生的“三阶段两转变”
企业怎么走到云原生,通常面临“三个阶段,两个转变”。
阶段1,一般以硬件设备为中心,应用在线下机房中,自动化程度低,没有统一的设备和应用管理能力。后期随着虚拟化软件的出现,在资源利用率、扩缩容灵活性上得到一定程度的提升,但并未从根本上解决基础设施与软件割裂、且运维复杂的难题。
阶段2,为了进一步追求资源的自动化,将基础设施和业务软件解耦,企业将应用放在云上,进入云化阶段。计算、存储、网络等各类基础资源得到池化,通过云资源管理平台,实现资源管理能力的自动化,屏蔽部分基础设施的差异,但是各个云资源管理平台差异化较大应用还是无法以完全标准化的模式构建,此阶段还是以资源为中心。
阶段3,为了进一步追寻应用的自动化,企业开始使用云原生平台,企业的关注点从资源移到应用上面。开始考虑如何将基础设施与业务平台融合,为业务应用提供标准的运行、监控、治理等接口,通常在这一阶段,企业还会将业务的通用能力下沉到平台侧,进一步实现应用的自动化。
开发者技术支持工程师(DTSE):为开发者提供全流程技术支持
DTSE全称开发者技术支持工程师,为开发者提供全流程的技术支持服务,截止23年底,已经服务了2700多家企业,解决了1100多个开发者需求。另外,DTSE本身面向云原生、大数据、AI、鸿蒙等多个技术领域,其中云原生是我们重点的支持方向之一。
DTSE跟普通技术支持相比的优势是可以提供线下的贴身服务,提供代码级技术支持,而且DTSE不仅围绕华为云240+云服务,还围绕各类主流的开源技术栈,帮助开发者上好云,用好云。更重要的是,DTSE具有诸多从传统应用到云原生应用转型的案例和经验。
客户案例实证,探索云原生实践,共筑高效云优化之路
以下是我们在实例拓展中遇到的一个客户,客户多次遇到业务流量陡增,弹性跟不上业务变化的情况,DTSE了解到客户诉求,从代码到架构跟客户一起梳理规划,短短2个月完成了初步的应用云原生化。
图为客户原有的技术架构
客户的业务发展过程中,架构上积累了很多的问题
- 首先,1到3号ECS服务器绑定了固定的公网IP,用于第三方服务访问,对于特定的API经过负载均衡解析,只路由至1到3号服务器进行访问,在流量洪峰时不支持扩容。
- 应用集群基于ECS整体部署和备份,备份镜像高达200G,既效率低下,又成本较高。
- 基于ECS整个的镜像做弹性伸缩,扩容时间长,不满足突发流量的要求,且一个ECS部署多个组件,缺乏灵活性,管理也复杂。
- 消息队列也由redis承载,在消息堆积等场景下可能会出现异常。
图为客户应用部署架构,从应用部署角度来看,1号服务器属于有状态部署,不支持伸缩,有额外的注册中心,所有的网关节点和业务节点必须向其注册自身,存在单点故障的风险。
业务中的定时、消息消费任务是通过基本的常驻进程实现的,也不支持扩容。
双向通信的业务逻辑,只会调用当前节点的Business Worker,无法做到集群负载均衡。
图中这个架构只是一个应用,通常在该服务器上还有其余应用系统,可能出现资源争抢的现象。
最后,我们还发现,业务代码混杂在一起,耦合严重。
CCE:高可靠高性能的企业级容器服务
为了满足客户云原生化的诉求,华为云DTSE提供贴身的技术服务,结合华为云产品能力,来解决客户问题。
第一款用到的产品是华为云的云容器引擎CCE,CCE是华为云提供的高可靠、高性能的企业级容器服务,有CCE标准版、CCE Turbo版和CCE Autopilot。
其中标准版提供插件管理、集群管理、节点管理、成本治理等功能,基于华为云上计算、存储、网络等基层资源,向上提供了原生k8s服务,开箱即用。
CCE Turbo版本,采用华为云擎天软硬协同架构,在容器网络、智能调度等方面进行了增强,采用云原生网络2.0,外部访问直通POD,此外还提供基于裸金属服务器的安全容器。
今年新推出的CCE Autopilot属于Serverless服务,在擎天架构的基础上新增了资源统一供给层,提供了极致的弹性。
这三款产品适用场景不一致,优先推荐CCE Autopilot
Serverless容器:极致性能、高效运维、丰富算力
我们使用的另一款与CCE搭配的服务是Severless容器产品,此产品是基于service基础设施资源底座提供的极致性能、高效运维、丰富算力容器平台。
这个和刚刚的Severless的CCE Autopolit有什么区别?可以简单这么理解,CCE Autopolit是集群性质的,能看到一个个集群,但是Serverless容器是POD级别的,没有集群的概念,直接操作容器。
此产品包含,以POD或POD Group管理维度的CCI服务,和新出的用于轻量应用搭建的轻量容器服务,提供极速的弹性。
在此案例用,只使用Serverless容器与CCE进行搭配,来应对突发弹性,所以我们选择CCI服务。
技术架构:容器化和配置中心带来产品性能和研发效能双提升
下面我们就用刚刚提到的云服务,对客户的技术架构进行了改造,使用CCE和CCI替代了ECS集群,将业务进行了容器化和无状态化部署。
综合考虑性能和成本,结合CCE和CCI的配置规则,弹性伸缩时,让容器优先在常驻的CCE节点上扩容,其次为CCE弹性节点,最后为CCI,缩容反之,在保证弹性能力的情况下,成本最低。
在弹性策略方面,利用CCE的prometheus插件实现了基于请求数的弹性伸缩策略,让负载更灵敏的贴合业务变化,应对突发流量。
除了弹性之外,还给客户新增了应用配置中心组件,统一管理配置,让配置可管可控可视。
最后整个应用集群通过Nat网关实现对第三方服务进行访问,实现单IP外置化,不再与集群强耦合,解决了特定API在流量高峰不能扩容的问题。
应用层将各个模块独立,降低耦合性
在应用层面,我们将客户的各个模块进行拆分独立,降低了整体的耦合性,比如Nginx、网关等等,允许各个模块单独弹性伸缩。外部访问路由,使用了CCE的Nginx Ingress Controller插件,同样可以在管理台界面动态更新配置信息,减少运维复杂度。
对于负载均衡则是基于K8s Service的能力,在CCE集群内部进行负载均衡。
业务容器化之后,镜像大小从原来的200G缩小为不到200M,既节省了备份空间,又可以在横向扩容时,加快扩容速度。
我们还针对每个容器启用了健康检查,从POD层面保证了业务正常运行,加快了系统故障的回复速度。
而刚刚在技术架构中提到的应用配置中心,也作为容器独立部署,无需额外的机器,节省了费用。
经过DTSE的贴身服务,客户的应用在应对突发流量的弹性、业务的可靠性、运维的方便性等方面都有很大的提升,不过并没有解决在原有架构上提到的所有的问题。因为很多问题,需要应用开发者进行重构。DTSE对于每种问题都给出了优化建议,DTSE也会继续的贴身服务,帮忙客户在云原生化的路上走的更远。
容器化后不能直接进行灰度发布
很多场景下,减小BUG带来的影响,需要进行灰度发布。在原应用架构下,应用使用ECS集群部署,当有新的版本需要服务,客户手动的将部分机器升级为新版本,等待新版本测试稳定,再将所有机器切换到新版本。
然而在容器化之后,应用使用Deployment部署了多个POD,但是Deployment是一个整体,其中的POD会完全一致,无法按照原来的模式将部分的POD更换为新版本。
对于这个问题,最先想到的是云原生的代表技术服务网格,可以被用于应用间的流量治理,那么华为云相关的产品就是ASM。不过客户在测试之后并不想使用该产品,主要因为服务网格中的Envoy在每个POD中都占用很多的资源,增加了成本,而且因为弹性伸缩的HPA策略是关联Deployment name的,ASM灰度发布后,HPA策略就失效了,综合以上原因,客户否决了这个方案。
基于CodeArts实现容器的自动灰度发布
为了更好的解决客户的这个问题,我们来看一下华为云提供的软件开发生产线CodeArts服务,这款产品是一站式,全流程的开发工具。覆盖了从产品需求、开发部署、到产品运维等软件交付全生命周期环节,我们在此问题中主要用到了流水线Pipeline和部署Depoly两个组件。
那么是如何做的呢?整个灰度发布的流程,可以分为这几个步骤。
- 首先发布新版本,减少旧版本的副本数,此时在POD层面,总数量不变,部分POD变成了新版本,其余还是旧版本,然后进行试点测试,并进行人工审批。
- 如果新版本有BUG,那就立刻回退,步骤与上一步相反,也就是回退旧版本副本数,删除新版本。
- 如果新版本没啥问题,那就可以把旧版本删掉,只保留新版本了,同时考虑HPA策略,步骤为:创建新版本弹性伸缩策略,删除旧版本,删除旧版本弹性伸缩策略。
对于上述步骤,人工操作也完全可以实现,但是为了避免紧急情况下的误操作,可以采用华为云CodeArts流水线,将上述步骤串起来,进行自动化,其中每个独立的步骤,可以使用CodeArts Deploy对接上对应的CCE集群下发指令完成。
此外,整个方案用到的CodeArts都是免费的,CodeArts提供了50人的免费版本,这个是ASM方案没法比拟的。最终客户接受了这个方案,整个项目也顺利完成。
更多推荐
所有评论(0)