gydtep

在权责方面，面向业务提供服务之前，由统一的团队负责从业务中抽象出源于业务而又不同于业务的数据域，再主导统一建设数据中间层，包括侧重明细数据预JOIN等处理的明细中间层、侧重面向应用可复用维度和指标的汇总数据中间层。

gydtep

在面向应用提供服务时，业务团队或深入业务线的数据团队有极大的自由度，只要依赖数据公共层，即可自由的建设ADS数据应用层。

gydtep

其主要功能包括：
-个性化指标加工：不公用性；复杂性（指数型、比值型、排名型指标）
-基于应用的数据组装：大宽表集市、横表转纵表、趋势指标串

gydtep

不管是数据公共层还是应用层，最终都需要面向业务提供服务。为了让业务部门找数据、看数据、用数据更加方便，我们将OpenAPI升级为能缓解业务变化对数据模型冲击的包括方法论+产品在内的OneService体系，使其在提供统一的公用服务的同时，兼容面向个性化应用的服务。

gydtep

在这个流程中，还没有涉及到对于流量精细粒度控制的高级灰度方案，但已经足够体现出其复杂性和操作难度了。如果仅仅依赖于简单的发布脚本进行管理，不但效率很低，还很容易导致顾此失彼，对系统稳定性造成巨大的风险。

gydtep

当某一个应用的性能出现瓶颈，需要通过增加实例数量来提升性能的时候，就需要引入新的计算资源。

新的计算资源从何而来呢？

gydtep

对于线下 IDC 而言，计算资源是需要预先规划的，扩容并不是一件简单的事情，可能会因为各种条件的制约而导致扩容无法实现。当然这种困扰在云计算时代不复存在了，为一个应用扩充计算资源是信手拈来的事情，但光有计算资源是不够的，还得在上面部署应用，并将应用容纳到微服务体系中。

gydtep

根据这个流程，如果需要扩容一个应用实例，保守估计也需要 20 分钟以上，其中购买、系统初始化、应用部署都需要占用大量的时间。假设系统流量突增，需要在 2 分钟之内紧急扩容，这个方案就无用武之地了。

gydtep

容器化相关技术能够更大程序的挖掘云计算的价值，在一定程度上帮助开发者解决这两个难题。

gydtep

在应用生命周期管理以及服务治理方面， Kubernetes 提供了比较完善的实现机制，通过构建 Deployment 资源，配合 proStop 和 postStart 脚本，能比较方便的实现滚动发布以及应用的优雅上下线。