尽量让调用发生在本中心，尽量避免跨数据中心的调用，一方面为了用户体验，本地调用RT更短，另一方面防止同一个数据在两个中心同时写入造成数据冲突覆盖。一般可以选择一种或多种路由方式，如ADNS根据地域路由，通过Tengine根据用户属性路由，或者通过sidecar方式进行路由，具体实现方式这里就不展开说了。
而主键之间是并发的，没有顺序而言。当接收消息的时候我们并不保证强顺序，采用LWW（Last Write Wins）的方式，也就是说我们执行当前的SQL而放弃前面的SQL，这样我们就不用考虑交换的问题。同时我们会根据消息的唯一性（实例+单元+数据库+MD5(SQL)）对每个消息做幂等，保证每个SQL都不会重复执行。而对于结合律，我们需要对每个操作单独分析。
世上没有免费的午餐，微服务技术让 IT 系统变得更敏捷、更健壮、更高性能的同时，也带来了架构复杂度的提升。对于开发者而言，要想更好的驾驭微服务架构，需要解决持续集成、服务发现、应用通信、配置管理、流量防护等一系列难题。
资源成本更深层次的分析
可能有的开发者会认为，目前的业务运行非常的稳定，在用户流量上并不存在明显的突增，所以扩容和缩容是一个伪需求，在将来也不会有这样的需求。这可能是对互联网业务的一种误解，因为完全没有扩容需求的情况是不存在的。
对于使用主流 Spring Cloud 体系或 Dubbo 体系构建微服务应用的开发者而言，如果需要引入一种方案降低资源成本，他的最终诉求一定包含两个方面：
（1）能否零改造成本，或者接近零改造成本；
（2）能否适配所有的业务场景。
定时弹性机制：对于会预期发生的周期性行为，可以设置定时弹性策略。举例：如果每天的上午 9 点是业务高峰，可以定时每天 8 点半增加实例数量，并在 9 点半减少实例数量。
成本分析
SAE 通过资源的实际使用量来付费，费用由两部分组成，每部分根据统计结果和计算方式进行费用结算，按小时出账单扣款。每个应用使用的资源计量方式如下所示：
多语言支持
对于非 Java 语言编写的应用，或者没有使用 Spring Cloud 等微服务框架的 Java 应用， SAE 能不能完美支持，并帮助企业降低资源成本呢？
对话式人工智能：改善客户服务体验
将丰富的客户行为数据、自然语言处理(NLP)和聊天机器人结合起来时会得到什么?通常无需人工干预即可改变客户联系和支持的潜力。
一书中定义了符合云原生架构的特征：12 因素、微服务、自服务、基于 API 协作、扛脆弱性。而由于这本书的推广畅销，这也成了很多人对云原生的早期印象，同时云原生也被 12 要素变成了一个抽象的概念。
