『高级篇』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.新人上手困难(现在的互联网公司,都是铁打的营盘流水的兵,过于复杂新人还没完全理解上手的时候,就已经离职了)
  3. 创新困难(成功引入新框架困难,就算成功引入学习成本极高)
  4. 可扩展性差(代码都运行在同一个进程里面,一个进程只能运行在一天机器上,给这个机器加多少内存,加多少cpu才能够我们这个项目用呢,有的框架对CPU要求高,有的框架对内存要求高,有的框架对硬盘要求高,其实最终选择了一个各方面都好的机器,是不是增加了成本的开支)

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

>>原创文章,欢迎转载。转载请注明:转载自,谢谢!

>>原文链接地址:

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章