语法服务响应和语法索引构建是完全异步的，互不影响，支持独立的资源扩缩。
对于企业来说，每时每刻都在产生海量的数据，数据采集作为数据体系第一环尤为重要。
因此在数据采集层需要建立了一套标准的数据采集体系方案，并致力全面、高性能、规范地完成海量数据的采集，将其传输到大数据平台。
针对不同计算场景，容器运行时有不同的需求。比如在传统数据中心，基于操作系统虚拟化的 RunC/Docker 容器可以很好地满足大部分业务需求；如何提升更好的安全隔离能力？KataContainer，Firecracker, gVisor, Unikernel 等新技术层出不穷。
尽管从应用研发的角度看，蚂蚁所使用的架构风格相比于原来发生了很大的变化，但从整体趋势来看，最主要的变化仍在于将和业务能力无关并且和基础设施相关的能力下沉。
云原生时代带来的最大变化在于基础设施和业务逻辑的真正解耦。此前，中间件逻辑存在于应用程序的进程中，而现在压测、限流等都可以在Sidecar中实现，从而解耦了基础设施和业务逻辑。然而，这种解耦是不断进行着的，即使在未来也很难做到业务完全不需要关注基础设施。
总体而言，解耦原则要求将最核心的业务链路隔离出来，使其与其它业务间的耦合尽可能小。
对这三块内容进行分析是微服务架构高可用设计的重要方面。比如，配置文件的可回滚和可灰度能力。与代码相比，配置文件的可灰度能力不够标准化，尤其是和业务或者运营相关的配置文件；数据也是如此，由于一些数据有多种来源，这些数据的可观测和可演练能力比代码差。从整体而言，代码的相关体系比配置文件和数据更完备。
近端在不同场合下可能有不同的名称。比如，如果将会员信息的全部请求都发给应用层，那么其所需要的集群数量将会非常庞大。由于会员信息的查询遵循了较为固定的范式，因此可以将会员信息的查询功能前置到收单服务，从而使收单服务不需要访问会员信息，而可以直接访问会员信息所依赖的服务。这本质上也是通过应用层设计来减小高可用的成本。
总的来说，将业务最顶端跟信息流相关的逻辑抽象出来，并且将这部分逻辑所依赖的数据异构一部分出来，这就能够使所有的业务实现不依赖于实际的处理逻辑，从而保证底层的任意一个节点发生宕机时整个系统的可用性。
扩大的方式也要从我们做大家用，变成我们做样板，大家模仿并衍生出更多优秀的应用案例。同时，加强应用领域和核心领域之间的链接，充分回流应用思想、应用方法、应用能力……反哺核心领域，用来自实际应用场景的客观需求，数据化驱动核心领域的精益迭代。
