聊聊架构

(最近我会写一些我对架构的理解和思考,本篇是第一篇,欢迎交流)

什么是系统架构?

从字面上理解,系统架构是系统的框架结构,是系统进行抽象之后的一个草图。它包含了系统中各个抽象组件的协作方式。

为什么需要架构?

好的架构能够降低系统的创造和维护成本,特别是维护成本。一个系统的创造成本低,而维护的成本大,特别是互联网应用,一般情况下把一个系统搞上线只需要一个月,但是有的系统搞下线缺需要几个月,而维护则需要数年。好的设计师不会在系统上线后对系统进行大的修改,从而减少系统的维护成本。

如果区分创造和维护两个阶段的话,架构师分为系统架构师和维护架构师,架构新的系统的是系统架构师,而维护老系统的则是维护架构师,程序员大多数愿意做新系统不愿意维护老系统,因为感觉没什么技术含量,但是维护老的系统反而更难,因为老系统的重构和改进更加复杂,维护架构师不仅需要读懂老系统架构设计,还要在不影响老系统功能的情况下,进行功能新增和重构。我的一位同事在对一个旧的系统进行重构之前,读了几个星期的代码,然后才开始设计改进方案。

架构设计的目标

设计的目标围绕着降低成本这个需求进行。设计的目标非常多,不同的系统架构目标也不一致,但是我觉得比较重要的架构目标有以下几个,可扩展性,灵活性和可插入性。

  • 可扩展性,新的功能容易加入到系统里,降低创造成本。
  • 灵活性,一处修改不会波及其他的地方,降低维护成本。
  • 可插入性,同样的功能可方便的替换,降低创造和维护成本。

那么如何实现这三个目标

  • 提高可扩展性:把不易变的抽象出来。抽象层要比实现层要更稳定,抽象层的变化要少。把变化的集中起来,比如把容易变化的功能放在单独一个系统或者一个模块里。
  • 灵活性:模块化,每个模块相互独立,减少模块之间的藕合度,修改不会互相传递。
  • 提高可插入性:模块化,服务化。

如何开始架构

当一块新业务放在你面前时,如何进行系统架构?我觉得需要进行以下几个步骤的思考:

  • 业务分析:输出业务架构图,这个系统里有多少个业务模块,从前台用户到底层一共有多少层。
  • 系统划分:根据业务架构图输出系统架构图,需要思考的是这块业务划分成多少个系统,可能一个系统能支持多个业务。基于什么原则将一个系统拆分成多个系统?又基于什么原则将两个系统合并成一个系统?
  • 系统分层:系统是几层架构,基于什么原则将一个系统进行分层,分成多少层?
  • 模块化:系统里有多少个模块,哪些需要模块化?基于什么原则将一类代码变成一个模块。

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/121015.html

(0)
上一篇 2021年8月28日
下一篇 2021年8月28日

相关推荐

发表回复

登录后才能评论