持续架构优化
有些企业在最初上云的时候，通过迁云的工具将应用和数据从原有数据中心迁移到云上。这些应用没有采用云原生的架构，无法利用云原生在弹性、韧性、安全、可观测性、灰度等优势，没有释放云的最大优势和效能。 通过分析后发现这些业务， 随着业务的发展，新的业务场景也会出现，云厂商也会推出新的产品类型和产品规格，通过持续架构优化，适配业务需要，并优化云资源使用，降低用云成本。
对应用架构进行云原生化改造
云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量敏捷、高度自动化和资源按需消费等特点。
以容器为代表的云原生技术作为云计算的服务新界面加速云计算普及的同时，也在推动着整个商业世界飞速演进。通过云原生化改造，企业可以充分利用云的强大能力，从云原生架构中获得更高的系统可用性与可扩展能力，利用云提升发布和运维的效率以及组建成本最优的架构。
云原生架构与传统架构的对比
应用容器化
软件交付的困难在于公司环境到客户环境之间的差异，以及软件交付和运维人员的技能差异，填补这些差异的是一大堆的用户手册、安装手册、运维手册和培训文档。容器就像集装箱一样，以一种标准的方式对软件打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而可以基于容器做标准化的软件交付。容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。
容器技术和容器服务ACK提升了企业 IT 架构敏捷性的同时，让业务迭代更加迅捷，为创新探索提供了坚实的技术保障。使用容器技术可以获得几倍的交付效率提升，这意味着企业可以更快速的迭代产品，更低成本进行业务试错。同时在互联网时代，企业IT系统经常需要面对促销活动、突发事件等各种预期内外的爆发性流量增长。通过容器技术，企业可以充分发挥云计算弹性优势，降低运维成本。一般而言，借助容器技术，企业可以通过部署密度提升和弹性降低将近一半的计算成本。
应用微服务化
过去开发一个后端应用最为直接的方式就是通过单一后端应用提供并集成所有的服务，即单体模式。随着业务发展与需求不断增加，单体应用功能愈发复杂。为了解决由单体应用模型衍生的过度集中式项目迭代流程，微服务模式应运而生。
微服务模式通过分布式架构将应用水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。
通过应用微服务化以后，应用中不同生命周期的模块将可以分离出来分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性，提升资源使用效率。同时也需要注意，微服务并不是为了微而微，这需要按照问题域对单体应用做合理拆分。通过微服务化架构的改造，将代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的资源部署更经济，成本更优。同时通过云上自动化能力应用迭代效率显著提升，相比人工软件交付效率也是一个巨大的进步。
企业级分布式应用服务 EDAS（Enterprise Distributed Application Service）提供了从开发、部署到治理的完整的微服务解决方案，是微服务托管和微服务管理的PaaS平台。同时支持Apache Dubbo、Spring Cloud等微服务运行环境。
微服务引擎 MSE（Microservices Engine）为用户提供服务注册发现、配置管理、网关接入、服务治理等高性能和高可用的企业级云服务能力。其中注册、配置中心全托管（兼容Nacos/ZooKeeper/Eureka），网关基于 Istio 构建并兼容 Kubernetes Ingress 标准 ，服务治理无侵入增强 Spring Cloud, Apache Dubbo 等开源微服务框架。帮助用户更便捷地使用开源技术构建自己的微服务体系。
MSE打通容器集群和微服务注册中心，轻松实现服务的自动发现、路由转发。支持超时重试、熔断降级、金丝雀发布等功能。
微服务架构下，业务通常采用流量网关 + 微服务网关的两层架构，前者负责南北向流量调度和安全防护，后者负责东西向流量调度和服务治理，MSE提供的云原生微服务网关, 将两层网关变为一层。将流量网关（ Kubernetes Ingress、Nginx）和微服务网关（Spring Cloud Gateway、Zuul等）合并，节省一半资源成本，并降低运维复杂度，云原生网关基于 Envoy 和 Istio 构建，性能优于传统微服务网关。并通过负载均衡、流量控制能力增强后端服务的可用性，确保业务系统顺利应对流量洪峰。
探索混合部署
为提升资源整体利用率，解决资源碎片问题并降低离线作业成本，将不同类型的在线、离线任务调度到相同资源上，通过调度和资源隔离等控制手段保障服务的能力称为在离线或离在线混部。两者区别在于是以在线业务为主还是以离线业务为主的资源进行复用。
从集群维度来看，混部也是将多种应用在一个集群内部署，通过预测分析应用特性，实现业务对集群资源的充分利用。
从节点维度看，混部是将多个容器部署在同一个节点上，这些容器内的应用既包括在线类型，也包括离线类型。根据应用对资源质量需求的差异，在线应用可以归纳为延时敏感型，通常对请求压力或访问延迟等指标有明确的要求，对资源质量较为敏感。离线应用可以归纳为资源消耗型，通常是一些计算密集型的任务类应用，有较好的容错重试能力，对资源质量的要求相对较为宽松。
混部的过程中，对于资源管理员而言需要对资源进行整体管理，洞察各类应用的资源容量、分配量和使用量，提升集群资源利用率，从而达到降低成本的目的。通过混合部署，离线享用在线空闲的计算资源，业务也能够享受到技术的红利。
混部分时复用
混部追求的是资源的极致利用，混部架构需要进行持续治理，从而达到稳定性、运维简化和成本优化的综合收益。
计算存储分离
面对业务不断增长带来的数据持续增加，不管是在线还是离线系统，其所需要的存储规模以及存储成本，成倍上涨。如果还是采取传统的分散式存储管理方式，不但带来高昂的管理分散式存储的成本，而且还会增加存储成本。
应用需要计算和存储分别可以高效按需扩容且节省成本的面向数据计算和存储场景的管理方式，此时分布式存储架构应运而生，基于此架构的数据管理也随之而来，分布式且共享的存储架构，让数据库的一写多读、多写多读、全球多活容灾、数据一致性等等能力特性有了技术基础。
存储计算分离架构
传统的存储方式，是单台服务器类型的，将计算资源与存储资源绑定在一起。因此一台机器CPU，内存与存储设备比值都是固定的。这带来的一个问题，就是我们会比较频繁的改变我们的机型，因每年我们的计算资源与存储资源的配比都在变化，业务数据的增长非常快。这也在某种程度上提高了机器的使用成本。
计算存储分离架构，解除了这两者紧密耦合的现状，可以分别进行弹性扩容。计算节点也不再需要考虑存储容量与内存容量的比例。多个节点上的存储资源能够形成单一的存储池，这能降低存储空间碎片化、节点间负载不均衡的风险，同时通过降低索引量，优化存储空间使用。同时存储容量和系统吞吐量也能容易地进行水平扩展。计算资源和存储资源解耦后，各自可以按不同的策略进行过保，在一定程度上降低了成本。
在云环境中，各类暂态数据、结构化和非结构化持久数据都可以采用云来保存，从而依靠“云”天生的计算存储分离架构进行实现。
拥抱Serverless
拥抱Serverless是架构优化的方向，是面向下一代的应用架构。服务化、模块化、可编排和可组装的Serverless架构将最大限度利用计算、存储、网络等全链路资源，提升整体资源利用率、缩短需求发布周期，极大地提升应用的研发效率。
函数计算是Serverless架构的一种形态，面向函数编程，基于事件驱动提供云服务之间端到端的解决方案。借助函数计算可以快速构建任何类型的应用和服务，并且只需为任务实际消耗的资源付费。使用函数计算，企业无需采购与管理服务器等基础设施，只需编写并上传代码或镜像。函数计算准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。
从架构抽象上看，当业务流量到来、业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭、调度业务进程，等待下一次触发，应用的整个运行时都委托给了云。
Serverless的增效降本
Serverless在事件驱动的数据计算任务、计算时间短的请求、响应应用、没有复杂相互调用的长周期任务有非常良好的效能表现。同时也需要注意，今天Serverless化架构并没有达到任何类型的应用都可以最优适用的地步，因此架构决策者需要关心应用的具体类型来进行架构设计。如应对有状态的应用，调度时如何保障上下文信息和应用的状态同步；又比如应用是否是长时间后台运行的密集型计算任务等，需要根据企业实际情况进行规划。