架构发展历史经历了这样一个过程：单体架构 -> SOA 面向服务架构 -> 微服务架构。

单体架构

image.png
在程序规模不大，开发人员很少的时候，单体架构有如下优点：

  • 开发简单
    • 单体应用的结构，所有代码都集中在一起，开发者不需要在多个应用之间来回跳转来寻找其中的调用逻辑。
  • 测试简单
    • 所有代码都在一个应用里，测试人员可以很方便的做到端到端的测试。
  • 部署简单
    • 因为一个应用就是产品功能的全集，所以在部署的时候，只需要部署一款应用即可。即使是集群部署，也不会增加多少复杂度：只需要将应用部署多份即可。
  • 开发迅速
    • 上面的各种简单，带来的就是软件功能可以快速实现。很多时候，实现需求的速度是项目成功与否的决定性因素。

所以，在开发简单独立的产品时，单体架构依然是第一优先选择。

单体架构存在的问题

1.1 单体架构 - 图2

WEB界面和各个业务模块最终打包在一个war包中，该war包包含了整个系统所有的业务功能，这样的应用系统称为单体应用。
存在的问题：

  • 系统资源浪费
    • 模块 A 与模块 B 都需要消耗10%的系统资源，而模块 C 却要占用 80% 的系统资源，运行一段时间后，模块C 就成为整个系统的瓶颈。从而降低系统的性能。
  • 部署效率低
    • 修改任意一个模块，哪怕是一行代码，都需要重新部署整个应用，部署效率较低。
  • 应用膨胀
    • 所有代码都在一个应用里，导致应用的代码量迅速上升，对于开发者来说，经常需要在海量的代码里找到自己需要维护的哪一行。对于 IDE 来说，一个应用内大量代码也会严重拖慢其运行效率。
  • 团队合作冲突
    • 这种冲突会体现在多个方面：
      • 开发阶段，很容易由于修改相同的代码导致代码冲突。
      • 部署阶段，又会因为“运行环境里跑的是谁的分支”而造成新的冲突。
    • 所有的这些冲突将会严重影响到团队的合作效率。

  • 运行效率&稳定性

    • 单体应用，由于逻辑都集中在一起，启动时需要完成所有的初始化工作；
    • 同时单一功能的问题也会因为运行在一个进程内，从而导致整个应用宕机。

      单体架构水平扩展

      1.1 单体架构 - 图3
      将相同的web应用部署到多台WEB服务器上，通过负载均衡技术缓解每台服务器的压力。如果流量加大，可以水平扩展更多的WEB服务器。但是会造成系统资源的极大浪费。因为我们水平扩展服务器主要是解决模块 C 的系统瓶颈，但对模块 A 和 模块B 也进行了水平扩展。单体架构原有的迅速、简单的优点，随着规模的扩大（功能、团队），会变得荡然无存。
      为了能解决这些问题，我们采用分而治之的办法，即将原来的单体应用拆分开来。

  • 应用该怎么拆分？

  • 拆分后又会有哪些新的问题产生？
  • 如何解决这些新的问题？

SOA 架构来帮我们解决。