很遗憾，微服务拆分没有标准，更多是经验，以下内容是从我写的书籍上复制的。我们从高内聚低耦合、业务模型、读写模式、演进式拆分、阶段性合并这些角度再来介绍服务拆分原则。1.高内聚、低耦合高内聚、低耦合是软件工程中的概念，在软件设计中通常用耦合度和内聚度作为衡量模块...

我觉得从2个层面考虑：1.公司角度从公司的角度考虑，如果公司对容器技术的支持力度大的话，可以先将偏app或者是无状态的服务往容器上迁移，这样可以快速的看到效果。2.技术角度技术角度考虑，主要涉及到业务了。首先要做的就是前端和数据库的分离，最好的结果是一个容器中运行一个服...

我觉得还是得看具体的业务场景。如果对数据实时一致性要求不高的业务，可以采用您提到的将交易系统和查询分开的方式，以降低对基础架构的要求。如果有数据强一致性的业务，如银行系统，还是会选择传统的集中式部署。这个时候硬件的性能、扩展性、稳定性，等等，依然是关键技术指标。...

12306是一个挑战性的项目，类似的项目首先应用层面的优化是最首要的任务。但单纯从IO性能的分离，就要细分一下业务类型，例如对历史数据和现有数据的读写占用的IO、对只读数据与常写或更新的数据占用的IO、对多文件类读写与数据库的读写时占用的IO可以开离，其实楼主可以结合实...