『高级篇』docker容器来说软件架构的进化（二）

原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
原文链接地址：『高级篇』docker容器来说软件架构的进化（二）

也工作了10年了，对于软件的架构也是不断学习总结，怎么样的发展到微服务的架构。

什么是软件架构

在软件的内部，经过综合各种因素的考量，权衡选择特定的技术，将系统划分不同的部分并使这些相互分工，彼此写作，为用户提供需要的价值。

• 哪些因素

  1. 业务需求
  2. 技术栈
  3. 成本
  4. 组织架构
  5. 可扩展性
  6. 可维护性
• 以我的个人经历
  1. 一层架构

     2007年在河南本地的一个公司实习，负责的是一个老系统，它用到了jsp和servlet，jdbc的技术，java早期的标准技术，在jsp里面看到了html，还看到了一大片一大片的java代码，直接写在jsp里面。在servlet里面有上千行的代码，300，500行都很平常的事情，包含了业务逻辑，返回给jsp的业务内容，业务操作，数据库操作。维护起来让你很崩溃，不过才毕业也就忍了，坚持了半年。后来要去济南。这种在极其简单的业务里面还是可行的，但是现在也看不到了。

2. MVC

   2008年去了济南，济南毕竟要全国知名的公司就进入了。虽然是996，但是感觉还好，至少代码不那么复杂了，虽然是jsp，java代码基本没有，分了很多文件夹，层次清晰分工明确，也学到MVC的三层架构。解决了代码调用杂乱无章，让代码清晰，通过各层之间定义接口的方式，让接口和实现分离，可以将原来的实现替换成方案，让别人理解，降低了沟通成本，维护成本，分工的明确各司其职，很长时间都是软件的架构经典模式。像SSH 和SSM其实MVC的实现。

3. dubbo

   2013年换了一家公司，dubbo那时候才出来1年，公司尝试用dubbo改造一个核心系统，为什么要用dubbo，因为里面java代码加页面代码100多万行，需求每个月还不断的添加，牛逼了我的哥！3年以上的人至少2-3个月熟悉都不一定能上手，只能想办法拆分，拆分的过程也是对老代码进行梳理和重构，dubbo的出现可以让前后端物理上隔离开来，完全变成2个可以单独维护的模块，从感官上复杂度就下降了一半，这种开发历程，在河南这边可能不太明显，在北上广应该都有类似的经历。多年的开发的人员。

其实上边的说的都是单体架构，很多目前的公司也都是单体架构，虽然dubbo，分离成了前后2个个体，但他并不是微服务。

什么是单体架构

功能，业务集中在一个发布包里，部署运行在同一个进程中。

• 优势

  1. 易于开发（方便开发人员开发）
  2. 易于测试（准备一台服务器，部署下就可以测试了）
  3. 易于部署（所有代码都打在一个包里面，直接拷贝一个war部署在服务器上，目录中）
  4. 易于水平伸缩（节点的复制，新建服务器，配置好运行环境，直接拷贝一个war部署在服务器上）
• 单体面临的挑战

  随着很多传统行业往互联网考虑，业务变化瞬息万变，系统的升级也越来越频繁，用户的数量快速增长，单体架构已经无法满足互联网的发展了，它有很多致命的硬伤。

1. 代码膨胀，难以维护（出现bug，分析定位成本都很高，随着代码开发，开发人员对全局的理解越来越缺失，修复一个bug，可能引入其他bug，恶性循环，导致难以维护）
2. 构建，部署成本大（代码越来越多，构建部署启动的时间越来越长，项目维护的人越来越多，大家都在构建，都在部署，难免互相影响，难免造成一个bug的修复，提交给测试验证的时间拉的很长，效率越来越底下）
3. 新人上手困难（现在的互联网公司，都是铁打的营盘流水的兵，过于复杂新人还没完全理解上手的时候，就已经离职了）
4. 创新困难（成功引入新框架困难，就算成功引入学习成本极高）
5. 可扩展性差（代码都运行在同一个进程里面，一个进程只能运行在一天机器上，给这个机器加多少内存，加多少cpu才能够我们这个项目用呢，有的框架对CPU要求高，有的框架对内存要求高，有的框架对硬盘要求高，其实最终选择了一个各方面都好的机器，是不是增加了成本的开支）

PS：综上所述，单体架构已经out了，老铁，可以考虑其他了，如何考虑下回继续说。