架构的演进
Don’t dream it, be it.
不要只是梦想,去实现它。
想写这样的这篇文章很久了,因为换过几家公司,导致我也或多或少的接触了很多各异的解决方案和项目设计.
不过我一直是思想上的巨人,行动上的矮子,导致我迟迟没有写下去,看的书越来越多,想法却越来越少,趁着还想写的时候,就先写一下
前言
我第一次接触代码的时候,是在大一寒假,当时导员让我们去预习下 C
语言的基础知识,然后我去找了一本 Dreamweaver 的书看了起来,然后做了个 VB
的小程序。大二的时候开始和导员学习,从古老的 Servlet/JSP 开始学,然后学习使用SSH
, 为了讲解切面,导员给我买了好多西瓜,吃了一个暑假也没吃完
一切都在变化
如果你已经开始从业 IT 行业,或者已经被xx产品或者老板折磨的死去活来,那你一定能明白什么叫 一切都在变化
!如果你还是学生,那你肯定也会遇到和某个损友约定好了时间,那个损友迟到3个小时还不见踪影。
在软件开发中,唯一不变的就是不断变化,上一秒的决定,下一秒可能就要推翻重来。无论我们怎么努力,软件依然变得越来越难以改变。由于各种原因,软件越做越大,逻辑、代码开始相互耦合,一开始的轻快编程变得越来越小心翼翼,关联Bug随之而生,生怕整个屎山在你面前土崩瓦解。
尽管我们总是喜欢为未来做出预留的规划,但我们永远看不清冰山之下到底是什么,不断变化的软件开发环境、需求、用户反馈使这一切变得困难重重。
在这不断变化的环境下,努力吸取前人的经验,规避风险,这正是我们要做的,那我们谈谈大概的项目结构发展吧
单体架构
Servlet/JSP
我接触的第一个完整的项目是在和导员一起的学习的时候,现在代码已经不知道在哪里了,以后会根据记忆实现一下,如果可能的话会在 Git
供大家看看史前代码
在当时的结构中,每个Servlet
负责处理一个请求,使用原生的JDBC
进行数据操作、然后将数据展现在 JSP
上,整个结构简单,在不复杂的逻辑中游刃有余,不过一些架构逻辑中出现了耦合,数据处理逻辑和展示展示逻辑存在耦合,这时往往会在 JSP
里面写下各种逻辑代码,甚至有的项目会直接在 JSP
上处理掉所有的业务逻辑,导致难以扩展和维护,来我们看看有缺点
优点
- 小项目开发简单(我骗了我自己)
缺点
- 代码耦合严重,导致修改困难
- 功能都在一个项目中,性能和伸缩性都难以保证,当项目越来越大,启动速度会越来越慢,编译也是一样
- 单一问题可能会导致整个项目无法使用
MVC
为了解决上面的问题,出现了分层结构,比较常见的就是 MVC
, 通过将各层分离开,各司其职,降低耦合,每层关注点独立且分离,通过明确的接口定义交互,对外封装细节,单一变更不会影响到其他项目
优点
- 各层分离,单独变更某个层很容易,比如将
JPA
改为Mybatis
,基本不会影响到其他逻辑 - 便于测试,分层结构更加容易对单层进行测试
- 更容易变更
- 低耦合,每个功能都是适当的内聚的,降低了耦合
缺点
- 所有的逻辑还是在同一个项目中,性能和伸缩性依然是个问题
模块化结构
相对通用MVC
, 这个更加去关注某个功能点或者模块,保持项目内某个模块的内聚,如果把项目比作第一层级的话,那模块就是第二层级,且相互独立,然后在模块内在使用MVC
分层,至于模块内部用什么,可以适当处理,只要保持 Facade
层独立即可
这种结构已经在逻辑上对功能划分出了不同的模块,但在部署时仍然时一个项目
微内核架构
这种结构一般出现在集成开发软件中,比如 VS Code, IDEA, Eclipse,Jenkins 等,通过在一些扩展点创建 hook,来使用插件,当然这种我并没有深入的接触过,也就不扯谈了
优点
- 内核完成,功能依靠增加插件来扩展,保证了相互隔离独立
- 核心和插件相互隔离
缺点
- 插件间相互通信复杂
- 内核需要协调各个插件的处理方式,鬼知道会遇到什么奇葩
共同的优缺点
以上讲的都是单体架构,则它们都有一些共同的特性
优点
- 项目结构单一、便于理解
- 部署简单
- 开发关注的并发点少,相对开发简单
缺点
- 单体项目容易局部问题导致整个项目不可用
- 性能难以扩展
- 代码量过大(我曾经有过单个项目一周删了 50W 行代码的经历)
- 必须使用同一个技术栈开发
集群
邓哥:咱这一个单体项目大概支持多人用,2000吧,
我:那多了怎么办,
邓哥:那就把这个部署2份,负载均衡下就可以了
我:哦 (负载均衡是什么鬼,Session 不是在内存中吗? 要怎么做呢)
在单体项目,为了提高性能,我们可以做一个集群,现有比较成熟的方案,例如使用 Nginx 来进行负载均衡,Session 复制实现Session 的使用
参考
- 微服务设计
- 导员的代码
- 峰鸟科技的代码
- 人人网代码
- 91金融代码
- 其他互联网代码