聊聊架构
(最近我会写一些我对架构的理解和思考,本篇是第一篇,欢迎交流)
什么是系统架构?
从字面上理解,系统架构是系统的框架结构,是系统进行抽象之后的一个草图。它包含了系统中各个抽象组件的协作方式。
为什么需要架构?
好的架构能够降低系统的创造和维护成本,特别是维护成本。一个系统的创造成本低,而维护的成本大,特别是互联网应用,一般情况下把一个系统搞上线只需要一个月,但是有的系统搞下线缺需要几个月,而维护则需要数年。好的设计师不会在系统上线后对系统进行大的修改,从而减少系统的维护成本。
如果区分创造和维护两个阶段的话,架构师分为系统架构师和维护架构师,架构新的系统的是系统架构师,而维护老系统的则是维护架构师,程序员大多数愿意做新系统不愿意维护老系统,因为感觉没什么技术含量,但是维护老的系统反而更难,因为老系统的重构和改进更加复杂,维护架构师不仅需要读懂老系统架构设计,还要在不影响老系统功能的情况下,进行功能新增和重构。我的一位同事在对一个旧的系统进行重构之前,读了几个星期的代码,然后才开始设计改进方案。
架构设计的目标
设计的目标围绕着降低成本这个需求进行。设计的目标非常多,不同的系统架构目标也不一致,但是我觉得比较重要的架构目标有以下几个,可扩展性,灵活性和可插入性。
- 可扩展性,新的功能容易加入到系统里,降低创造成本。
- 灵活性,一处修改不会波及其他的地方,降低维护成本。
- 可插入性,同样的功能可方便的替换,降低创造和维护成本。
那么如何实现这三个目标
- 提高可扩展性:把不易变的抽象出来。抽象层要比实现层要更稳定,抽象层的变化要少。把变化的集中起来,比如把容易变化的功能放在单独一个系统或者一个模块里。
- 灵活性:模块化,每个模块相互独立,减少模块之间的藕合度,修改不会互相传递。
- 提高可插入性:模块化,服务化。
如何开始架构
当一块新业务放在你面前时,如何进行系统架构?我觉得需要进行以下几个步骤的思考:
- 业务分析:输出业务架构图,这个系统里有多少个业务模块,从前台用户到底层一共有多少层。
- 系统划分:根据业务架构图输出系统架构图,需要思考的是这块业务划分成多少个系统,可能一个系统能支持多个业务。基于什么原则将一个系统拆分成多个系统?又基于什么原则将两个系统合并成一个系统?
- 系统分层:系统是几层架构,基于什么原则将一个系统进行分层,分成多少层?
- 模块化:系统里有多少个模块,哪些需要模块化?基于什么原则将一类代码变成一个模块。
原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 聊聊架构
辛苦了!!,对想学技术的人来说帮助真的是太大了
多谢支持
在业务分析之后,先按照服务进行粗粒度划分,然后服务内部在进行模块划分。服务和模块的一个不同在于服务之间是跨进程的调用,依赖是运行时的。模块之间往往会本地调用,会有很多编译期的依赖
“提高可扩展性”,这一点我很茫然。
能否结合具体的例子?例如下面的这个例子:
系统主要业务介绍:教师根据开设课程,上传课程的视频,文档(视频为主),学生可以在线观看课程视频,或者下载视频,文档离线观看。用户数目测在10000左右。
如何开展?
补充一条,架构除了业务分析、系统划分、系统分层外,最后实现完整的业务链条,必须考虑系统间的通信,因为最后一个完整的生态系统肯定是由若干个子系统组成的,子系统之间的通信关系是我觉得有以下几种方式。
独立运行、较弱依赖、相互依存。子系统提供的服务方式也分几种,本地API、远程调用、系统服务,调用的方式也有同步与异步等等。同步也得考虑繁忙超时等问题、异步得考虑结果回调等。基于服务的调用,得考虑重试机制等等诸多问题。所以系统间的通信也是架构中最重要的。