凌云时刻

云原生架构转型需要面临的挑战

有人提到，他用了阿里云、华为云、微软云……用了很多，这是我们现阶段上云时具有的一个普遍特征——大家处于多云的场景。但实际上，我发现真正多云并存的情况并不多，因为维护多云是一件很困难的事情。这里的多云其实是一个很大的概念，除了不同厂商，还有不同架构——比如有x86的、ARM的，有国产化的、非国产化的等等，这就使得我们基础设施架构变得越来越复杂。对于用户来讲还好，但对运维的同学来说，这件事情却是苦不堪言。

在云原生化过程中，我们永远离不开开源社区的支持，包括阿里中间件在内，也是积极投身开源社区。开源是把双刃剑，它具有技术方面的优势，但没有运维方面的保障。当一个新兴的开源技术出现时，我们到底该不该选，怎么选，选哪一个，其实都是很困难的一件事。我们怎么能做到，选择的开源技术是最佳实践，同时它又确实能解决我们的问题呢？

前面同事的分享提到在CNCF上有超过1000个云原生项目，可到底哪一个是适合我的呢？光是解决一个调度问题就有很多的项目，解决一个函数计算也有很多项目，究竟哪个项目真正适合我，这些都没有答案。每个企业在创新的过程中，或者在上新一个业务的时候，都要去思考这样一个问题还是挺困难的，我们还有很多坑要去趟，要很多的经验去积累。

云原生中间件展望

刚才提出了一些问题，下面我们就在几个领域给大家做一个展望。

 应用及微服务

在座的各位对应用以及微服务这个领域都不会很陌生，云原生包括容器化，也包括微服务场景。这里提出的几个问题相信大家应该也是感同身受的。

• 首先，各个云厂商提供的都是点状的解决方案。比如弹性伸缩的能力，会存在这样的一个服务，提供一个现成的降级能力，但是能不能把这些能力串成一个场景，其实要靠各位的奇思妙想。

• 其次，我们在谈微服务的时候，以前更多的是谈运维场景——包括监控也是运维场景，但是其实我们知道，在微服务领域里面，不单是服务调用，不单是运维场景，还有很多，设计、开发、测试、部署、应急等都是应用开发和微服务领域的产品要解决的问题。

• 第三，我们在云原生化、容器化过程中，有些应用是从虚拟机时代迁移过来的，肯定是双模并存的。

• 最后，多语言场景。

未来，在微服务领域，我们希望走一种双模或者多模的形态，比如虚拟机和容器并存。一些网关的场景，我们以前有微服务网关，现在到容器里面有容器网关，这两者是不是可以统一起来。还有多语言，我们不希望多语言应用迁云的时候，还要我去改造一遍代码。服务网格是专门用来解决这个问题的。最后，我们需要提供场景化的解决方案，不是点状的给大家一些乐高零件，那是乐高专家玩的事情，普通的玩家需要的是你给我一座迪士尼城堡。

 云原生消息服务

刚刚我们提到了微服务领域，现在再来看看消息。通过消息，我们可以将微服务调用异步解耦，大大丰富了微服务的应用场景，还有削峰填谷，这都是传统的消息常见的场景。但是当我们提到消息的时候，心中会有两个概念，我们知道Rocket MQ和Kafka是两种不同的消息系统，但都是消息，为什么它们是不同的呢？就因为它们的场景不一样。我们知道Kafka是用来做流式处理、大数据处理、流式计算的，那这两者可否统一起来？所以我们定义的新一代信息体系是消息、事件、流三位一体的，而且是具有标准化的开放性融合的消息处理平台。

 云原生技术中台

最后，当我们有了消息，有了微服务，我们就可以把它想象成中台。阿里一直喜欢提中台，但这个时候我们提出来的是云原生技术中台。当我们认为业务对我更重要，我的核心技术能力是可以由云厂商提供的时候，此时云厂商的下沉能力就变成技术中台，里面会提供很多技术组件、解决方案供大家去使用。

刚刚我们在多云、混合云的场景下提到了边缘场景，当真正有中心、有本地、有边缘的时候，我们如何通过中间件或者云原生的技术帮助大家去解决呢？同时我们有AI、大数据，这些东西都有容器或中间件产品，但是需要的能力不一样。比如我是边缘业务，我需要解决网络偶尔通偶尔不通的问题，但如果是中心业务，我可能就不需要考虑这些问题，我们需要分场景来给大家提供不同的解决方案。

作为一个中台，最重要的是能够迅速落地，这里专门抽出了一个社区版的概念。刚才有同学提出这个东西很贵，只有它能产生业务价值我们才会去用，但是如果我没有用过，怎么知道它能给我产生多少业务价值？这个时候我们就需要社区版来支持，免费试用。先试一下，然后在上面真实地去做研发测试。最后，再去上线迁移。这样才能决定这东西对我确实是有用的，我很愿意上来用，因为我有收入。这种方式对大家都好。

↓↓↓