应用程序存在着许多监控操作。随着Sidecar将很多能力下沉，包括访问RPC和DB，此前以中间件形式实现的监控操作，现在则以切面形式来实现，二者有很大的区别。
值得注意的是，这是一个最复杂的配置灰度设计，实际上的灰度设计比这个场景要简单地多。
设计下沉和异步化，从以往针对需求的设计进化到针对业务的设计，从设计趋势和社会发展、技术进步三个角度出发，以设计语言为依据，以设计系统为规范，提供设计范式，由模型根据设计范式进行自动化设计生产，从一个 UI 方案衍生出 N 个 UI 方案、从一个 Element 衍生出 N 个Elements。
除了数据需要进行异构处理外，一些计算规则也需要迁移到信息流处理中，比如商家的店铺信息处理等。数据和计算规则的异构使我们能够实现解耦，这种设计对应着一个标准化的范式。几乎在所有的业务场景都能看到这种设计。
首先，智能化思维解决问题的过程很简单，简单的过程就代表了确定性：一定会有答案。其实，这就像人生的困惑，每个人都有自己的答案，即便我们告诉模型所谓的正确答案，模型训练后对未知问题也不一定给我们期待的答案，但是，模型一定会给我们一个答案。
如果要修复埋点问题，则需要满足下面三个条件：
能够无二义性的识别错误数据。
完备的数据，可以计算出正确的数据。
需要在合适的时机进行计算。
其实对于错埋和多埋的修复场景，就是在上报SDK前这一时机进行计算。
这其实并不是一个好主意，每一个计算资源都是需要成本的，资源池虽然能够解决计算资源快速投入使用的问题，却造成了巨大的浪费。另外，到底规划多大的资源池，也是一件很伤脑筋的事情，池子越大，造成的浪费就越大，但池子太小，又可能满足不了扩容的需求。
再谈谈为什么要做多中心容灾，以我所在的CDN&视频云团队为例，首先是海外业务的需要，为了能够让海外用户就近访问我们的服务，我们需要提供一个海外中心。但大多数业务还都是以国内为主的，所以国内要建双中心，防止核心库挂掉整个管控就都挂掉了。同时海外的环境比较复杂，一旦海外中心挂掉了，还可以用国内中心顶上。国内的双中心还有个非常大的好处是可以通过一些路由策略，分散单中心系统的压力。这种三个中心且跨海外的场景，应该是目前**多活最难实现的了。
对于企业来说，每时每刻都在产生海量的数据，数据采集作为数据体系第一环尤为重要。
因此在数据采集层需要建立了一套标准的数据采集体系方案，并致力全面、高性能、规范地完成海量数据的采集，将其传输到大数据平台。
接下来将以系列文章的形式，和大家分享阿里云容器服务团队在云原生计算领域的探索和思考。本文主要聚焦在云原生基础设施。
