多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案如下：
将共享的代码拆分为独立的类库，然后使用依赖管理策略去加载它们。所有部署的基准代码相同，但每份部署可以使用其不同的版本。比如，开发人员可能有一些提交还没有同步至预发布环境；预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码，我们就认为它们只是相同应用的不同部署而已。
管理进程:后台管理任务当作一次性进程运行
一次性管理进程主要指一些管理或维护应用的一次性任务，比如，运行数据迁移，运行一些提交到代码仓库的一次性脚本等。它们应该和正常的常驻进程使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置，基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。
云原生数据仓库 AnalyticDB PostgreSQL 版，支持标准 SQL 2003，兼容 PostgreSQL / Greenplum, 高度兼容 Oracle 语法生态；具有存储计算分离，在线弹性平滑扩容的特点；既支持任意 维度在线分析探索，也支持高性能离线数据处理；是面向互联网，金融，证券，保险，银行，数字政务， 新零售等行业有竞争力的数据仓库方案。
全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施 的开发、运维、安全、高可用等工作；
Kubernetes 已经成为云时代的操作系统。对比 Linux 与 Kubernetes 的概念模型，他们都是定义了开放的、 标准化的访问接口；向下封装资源，向上支撑应用。
容器我们需要坚定的使用 Kubernetes（ACK），结合零售行业的特性，Serverless 不是强需求， ASK 短期可以不用。容器建设上需要考虑多租户容器逻辑和物理隔离，多租户容器运行时管理等。
MMA2.0迁移工具是最近推出的一个工具，可以帮助用户把数据从现有的大数据系统里迁移到MaxCompute上，这些工具都是基于SDK开发的，都是通过SDK传输。
ODPS Endpoint是服务的一个入口，现在在公共云上应该有21个region，包括金融云和政务云，中国有7个，海外有14个。每个region的endpoint是不一样的，使用时需要找到自己购买的region服务，并正确填写endpoint进去。
Pack并不是写网络的，而是写内存的。因此，不同于writer，flush是可以重试的，因为数据都在内存里。并且Pack也没有状态，不需要关心writer的Block ID等等。另外，因为flush成功后数据就可见了，所以session也没有commit这种状态。
在我的理解，软件架构主要目标是解决下列挑战：
1、控制复杂性。由于业务的复杂性，需要我们用更好的手段帮助研发组织克服认知障碍，更好的分工协作。分而治之，关注点分离等手段皆是如此。
