第三大块是应用架构，目前我们中台里面做的比较多的叫星环，星环说白了，它想达到架构的本质目的就是将单纯的代码共建模式，抽象成横向和纵向的业务包模式，做到业务与业务隔离，业务与平台隔离。
XA 事务在并发行上有一定的局限性，在执行的过程中，我们必须使用类似 Spanner 锁定读写的事务策略，为所有 SELECT 操作带上 LOCK IN SHARE MODE ，造成读写相互阻塞。
首先从 Cloud 来理解，云可以看作是一种提供稳定计算存储资源的对象。为了实现这一点，云提供了像虚拟化、弹性扩展、高可用、高容错性、自恢复等基本属性，这是云原生作为一种云计算所具备的第一层含义。第二层要从 Native 来看，云原生和在云上跑的传统应用不同。一些基于公有云搭建的应用是基于传统的 SOA 架构来搭建的，然后再移植到云上去运行，那么这些应用和云的整合非常低。
高效的会议：缩小会议范围，常规会议不应该超过 45 分钟；限制“意见领袖”的发言时长；会议中不允许开小差；会议中的分歧不应该延伸到会议之外。
例如，与本地服务器或私有云相比，软件公司更倾向于在公共云中运行代码。在软件公司工作的云原生开发人员中，近三分之二在公共云中运行代码，同时该行业一半的开发人员在私有云上运行代码。
一些零售商也将在边缘部署人工智能，以最快的速度和最小的延迟在本地处理本地视频，这在某些情况下为非接触式且无需收银人员的购物打下了基础。商店可以使用摄像头和边缘人工智能来检测远处的物体，并快速处理相关信息。这些数据有助于优化客户等待时间、库存货架和店内体验。
因此，微服务架构在本质上就是对弹性伸缩有着强烈诉求的，在弹性伸缩的过程中，不管是单应用的水平弹性伸缩，还是整套环境的启停，资源利用率都对最终的资源成本起着决定性的作用。如果能想办法提升资源利用率，就能为企业节省大量资源成本。值得我们重视的是，绝大多数的微服务应用的资源利用率都是非常低的。
算法总结
优点：
完全是一个无状态机，无网络调用，高效可靠。
缺点：
依赖机器时钟，如果时钟错误比如时钟不同步、时钟回拨，会产生重复Id。
消息跨单元传输
为了很好的支持跨单元数据同步，我们采用了MNS（阿里云消息服务），MNS本身是个分布式的组件，无法满足消息的顺序性。起初为了保证强一致性，我采用消息染色与还原的方式，具体实现见下图：
从采集系统中收集了大量的原始数据后，数据只有被整合、计算才能被用于洞察商业规律、挖掘潜在信息，实现大数据价值，达到赋能商业、创造商业的目的。从采集系统中收集到的大量原始数据，将进入数据计算层中被进一步整合与计算。
