比如阿里早期运维工程师是特别多的，但是随着云原生、容器、虚拟机等技术革命，带给这个职位更多的变化，提出了 DevOps、SRE、AIOps 等，运维领域在不断的被自动化掉，所以说创新是无处不在的。
有人曾说架构有个“看山四境界”，面对的场景，一个比一个复杂，解决的问题一个比一个困难。在人类早期社会时，就是单纯的为了生存，吃喝保暖、生老病死。
等到我们工作的年限越来越久，就会发现，当我们的参照系发生变化，就不会执着于自己的性别身份，反而会更加专注于业务、架构、问题本身。男程序员和女程序员又有什么不同呢？
海量接入
终端场景接入的是终端设备，而服务端接入的就是服务器，前者在量级上肯定远大于后者。
存到 Topic 队列后会有一个 notify 逻辑模块来实时感知这个新消息到达，然后会生成消息事件（就是消息的 Topic 名称），将该事件推送至网关节点
一个重要问题，就是 notify 模块怎么知道一条消息在哪些网关节点上面的终端设备感兴趣，这个其实就是关键的匹配查找问题。一般有两种方式：1）简单的广播事件；2）集中存储在线订阅关系（如图中的 lookup 模块）
使用了一个 Commitlog 文件来保存所有的消息内容，再使用 CQ 索引文件来表示每个 Topic 里面的消息队列，因为 CQ 索引数据较小，文件增多对 IO 影响要小很多，
最后导致系统非常难以维护。而且更糟糕的是，出来混总是要还的，前期的领域模型设计的不好，不够抽象，如果你的系统会长期需要维护和适应业务变化，那后面你一定会遇到各种问题维护上的困难
一个开发工具，等。但是他不清楚这些系统应该具体做成什么样子。这个时候，我认为领域专家就非常重要了，DDD也非常强调领域专家的重要性。因为领域专家对这个领域非常了解
比如，也许我们一开始将商品和商品的库存都放在商品中心里，但是后来由于库存的维护越来越复杂，导致揉在一起对我们的系统维护带来一定的困难时，我们就会考虑将两者进行拆分，这个就是所谓的业务垂直分割。
