值得一提的是，这并不是微服务体系下流量绑定的标准配置，而是阿里的应用开发人员和中间件人员提出的业务隔离设计。随着上云等措施，这种设计逐渐内置到基础设施中，成为一个典型的业务隔离设计。
充分发挥在大数据海量、多样性方面的独特优势。借助这一统一化数据整合及管理的方法体系，构建企业数据公共层，并可以帮助相似大数据项目快速落地实现。
主要功能包括：
-个性化指标加工：不公用性；复杂性（指数型、比值型、排名型指标）
-基于应用的数据组装：大宽表集市、横表转纵表、趋势指标串
微服务的核心理念是，系统中的各个服务可被独立开发、独立部署，独立升级，各个服务之间是松耦合的。云原生应用架构理念是进一步强调架构的松耦合，降低服务之间相互依赖的程度。
。同时，加强应用领域和核心领域之间的链接，充分回流应用思想、应用方法、应用能力……反哺核心领域，用来自实际应用场景的客观需求，数据化驱动核心领域的精益迭代。
D2C 技术体系升级，引入 S2C 能力，形成 P2C 端到端业务交付平台：在无状态简单UI代码和简单前端业务逻辑代码生成基础上，升级到复杂UI代码和复杂业务逻辑代码生成，同时，复杂UI代码里对状态进行识别和处理，生成带状态变化的UI逻辑代码，端侧调用JSBridge、数据和服务接口的业务逻辑胶水层代码，服务端调用数据和服务接口的业务逻辑胶水层代码。
服务端下沉和抽象化、原子化，提供标准的、原子的领域能力，由 S2C 体系进行能力的理解，并通过需求的约束对调用逻辑：胶水层代码 进行生成。
微服务思想以及相关的技术为 IT 架构的发展带来了一系列深刻的变革：
易于开发和维护：一个应用只会关注一组特定的业务功能，通过服务拆分，能减少应用之间的耦合度，让开发和维护更加简单。
这其实并不是一个好主意，每一个计算资源都是需要成本的，资源池虽然能够解决计算资源快速投入使用的问题，却造成了巨大的浪费。另外，到底规划多大的资源池，也是一件很伤脑筋的事情，池子越大，造成的浪费就越大，但池子太小，又可能满足不了扩容的需求。
因此，微服务架构在本质上就是对弹性伸缩有着强烈诉求的，在弹性伸缩的过程中，不管是单应用的水平弹性伸缩，还是整套环境的启停，资源利用率都对最终的资源成本起着决定性的作用。
