单体架构拆分微服务一

单体架构

UML

优势

• 快速迭代
  刚开始搭建项目时能够快速迭代需求，不需要多个服务反复切换开发，多方配合处理。

• 部署便利
  部署只需要部署一个服务即可。

• 技术栈单一
  开发只需要会一种技术栈就能独立的完成开发

• 用人成本低
  往往一个开发就能独立完成从业务逻辑处理到DB的整个流程

劣势

• 维护困难
  当开发逻辑越堆越多，逻辑耦合在一起就很难接手维护，通常可能维护摸一个模块的人，可能需要去理解熟悉大多数响应场景逻辑。

• 测试困难
  如只需要测试一个小模块时，因为单体服务的原因可能需要吧涉及到的业务功能部分全部测试一遍以及性能相关测试都需要跑一遍

• 技术栈单一
  比如内容服务可能需要爬去数据，可能使用Pythons会更合适

• cpu内存等硬件无法根据需求拆分
  在某些模块比如活动可能并发较高需要多一些cpu，比如内容模块部分可能需要更多的内存。

• 工具版本过于依赖，无法良好的升级
  比如说微信等第三方服务的调度，可能第三方已经升级了某部分的处理方案，但是因为工具包的原因可能导致需要全局变更。

• 系统启动慢
  内容越堆越多项目启动可能由毫秒级别变成分钟级别

• 系统错误隔离性差、可用性差
  任何一个模块的错误都可能导致整个系统瘫痪。

---

因项目在开发过程中产生的问题分析了如上优劣势。
在单体架构刚开始开发的时候，非常便利且快速的进行需求开发迭代，也不需要投入过多的人，仅仅一个前端一个后端即可完成大部分的研发，部署项目时简单的一行命令就搞定，设计好初始化的架构后就可以直接投入开发能够快速迭代。但是随着时间的推移，需求的增多，内容的增多，代码复杂度的提升。导致维护困难，新人一段简单（一个小时就可理解）的逻辑业务代码可能要理解一到两天时间。项目启动时间由最开始的30毫秒变成3分钟，每次调试个bug可能就需要多次启动项目每启动一次项目就要浪费3分钟，实在过于浪费时间。且项目启动对开发人员的电脑配置也有要求，如果内存少于12G项目都启不来。而且每次需求迭代测试同学测试的时候，可能测模块A的同事需要重启服务，这就导致测模块B的同事需要等待。而且服务可靠性，可用性很低，经常由于一个模块的问题导致别的客户端全部挂掉。