UDPA（Universal Data Plane API）是基于 xDS 协议而发展起来，以便根据不同云厂商的特定需求便捷地进行扩展并由 xDS 去承载。
商业能力是零售云对外交付的输出产物，商业能力建设和商业能力研发平台建设是重心。当零售云中台的开发和版本演进变成一个常规化的easy事，商业能力对外交付变成快速可持续迭代的状态，那么我们的产品建设就初成形态了。
现在有两套API，分批量数据通道和流式数据通道。
批量数据通道目标的场景单并发的吞吐量很大，这种理想的场景是传量大的数据，一次一批，QPS和并发都不能特别高，但是单并发的吞吐量可以做得很大，这个在API上也有一些优化。
上图中可以看到，批量上传的流程是先创建一个upload session (第31行),然后open writer，用writer去写数据，然后close，再upload session加commit。
另外，流式服务是支持异步数据处理的，也就是除了保证用户通过流式写上来的数据可读之外，服务端还有一个机制能识别出来新写进来的数据和存量数据，可以对新写出来的数据做一些异步的处理，比如zorder by排序和墨纸。
3、减少开发环境和生产环境的差异，并使用持续交付实施敏捷开发。
4、提升应用的可移植性，适合云化部署，降低资源成本和管理复杂性。
与传统同步处理方式相比，异步事件处理存在与事件排序、幂等性、回调和异常处理相关的要求，整体设计难度更大一些。
在 Kubernetes 中，业务应用可以提供一个 liveness 探针，可以通过 TCP、HTTP 或者命令行方式对应用就绪进行检测。对于 HTTP 类型探针，Kubernetes 会定时访问该地址，如果该地址的返回码不在 200 到 400 之间，则认为该容器不健康，会杀死该容器重建新的容器；
还是倾向于出现问题后，可以通过简单抛弃和替代进行恢复（Cattle）。云原生架构的建议是：允许失败发生，确保每个服务器，每个组件都能够在不影响系统的情况下发生故障并且具备自愈和可替代能力。这个设计原则的基础是应用配置和持久化状态与具体运行环境的解耦。Kubernetes 的自动化运维体系让服务器的可替换性变得更加简单。
不同的外部中间件通过 Java Connector Architecture 规范实现与应用服务器的插拔。应用通过 JNDI 在运行时实现与具体资源的动态绑定。Java EE 将系统的 cross-cutting concern下沉到应用服务器来解决，让开发者只关注应用的业务逻辑，开发效率有了较好的提升；同时减轻应用对环境和中间件实现的依赖，比如可以在开发环境中用 ActiveMQ ，在生产环境中使用 IBM MQ 替换，而无需修改应用逻辑。
