容器和 K8s 并非一定要捆绑使用，在一些新型的 PaaS 服务中，例如阿里云的 Serverless应用引擎（SAE），底层将虚拟化技术改造成容器技术，充分利用了容器的隔离技术
上线了一个新的项目，想快速验证，不要出故障，同时控制人力的投入成本；
业务体量上升快，用户越来越多，业务稳定性有点 hold 不住
本文将重点讨论下这个比较现实的问题。同时根据网友的试读建议本文进行了思维导图的总结，可以保存收藏。
前面几篇文章中，笔者给大家阐述了 DDD 领域驱动设计的三大过程，重点围绕如何通过战略设计与战术设计进行 DDD 落地实践进行了详细的讨论，但是还没有涉及到工程层面的落地
那这个论坛的核心业务是确定的，比如都有用户发帖、回帖等核心基本功能。比如电商平台、普通电商系统，这种都属于网上电商领域，只要是这个领域的系统，
这个思路，和传统的分析、设计、编码这几个阶段被割裂（并且每个阶段的产物也不同）的软件开发方法学形成鲜明的对比。
所以服务间的消息分发是消息的基础诉求。然而我们看到，在消息（队列）这个领域，近些年我们业界有个很重要的趋势，就是基于消息这份数据可以扩展到流批计算、事件驱动等不同场景，如 RocketMQ-streams，Kafka-Streams、Rabbit-Streams 等等。
广播比
服务端消息比如交易系统发送了一条订单消息，可能有如营销、库存、物流等几个系统感兴趣，而终端场景比如群聊、直播可能成千上万的终端设备或用户需要收到。
有些时候，需求方，即提出问题的人，很可能自己不清楚具体想要什么。他只知道一个概念，一个大的目标。比如他只知道要做一个股票交易系统，一个灰度发布系统，一个电商平台，一个开发工具，等。
订单中心：负责订单的生成和生命周期管理；
交易中心：负责交易相关的业务；
库存中心：负责维护商品的库存；
促销中心：负责各种促销活动的支持；
