设计基础-软件架构笔记
看了网络上的一些资料,也看了一些书本上的资料。
总体上感觉就是混乱。结合自身的经验和体会,列出几个关心的要点和个人心得。
实际的东西,读者还是去看看有关更加专业的书籍。
一、定义
”名不正,则言不顺。言不顺,则事不成“。
简而言之,”软件架构“可以理解为解决软件设计的通用方法,是关于不同功能/结构之间的组合方法。
或者,可以简单类比为一个集体内部,应该如何协作以便更好地解决问题;一个军队内部,不同的作战单位应该如何互相协作。
从软件工程的角度出发,”软件架构“算是比较上层的,宽泛的技术概念,但要理解为工程管理概念未尝不可。
所以,世间万物就是这样:具有多个角度,又互相联系。
二、混乱的说法
因为历史的缘故,关于”软件架构“,在百度等地方可以搜索出非常多的内容,着实混乱得很。
例如:
五种常见软件架构 - 时间朋友 - 博客园 (cnblogs.com)
10种常见的软件架构模式 - 林本托 - 博客园 (cnblogs.com)
程序员必知的7种软件架构模式 - 知乎 (zhihu.com)
以前常常谈论"C/S","B/S","SOA","SAAS",还有其它一些名词。
再换个角度,还有其它名词,例如”电商架构“、”企业架构“、”大型互联网架构“,等等。。。
所以整体还是有点混乱,因为角度不同,所以同个东西可能会有不同叫法。
标准不是非常统一,也不算非常严谨。
一般大学中,相对缺乏讨论这个问题(非常可惜)的学科。
须知,由于人类认知的特点,和局限性,如果不先来个相对统一的大概念,那么必然会导致有关人员的思维混沌。
三、常用架构
这里摘取几个个人认为比较有用的架构,主要来自五种常见软件架构 - 时间朋友 - 博客园 (cnblogs.com)
1.分层/层叠-上层依赖下层(一般而言)。特点:简单明了。现在人人都会
2.事件驱动-组件之间靠事件来驱动。没事就没有关系。要算”架构“比较勉强
3.微核/插件架构-非常典型的是eclipse的设计。好处是足够扩展和灵活,缺点是有点吃性能,如果没有好好管理插件。
4.微服务-某种程度上足够灵活,但消耗偏大。常用于处理不是那么关键的任务,仅仅是因为微服务更好伸缩。 不是特别大的事务,建议不要上这个,否则你会后悔的,唯一的受益者就是那些所谓的”技术爱好者“。
5.云架构? 核心就是花钱办大事,把功能拆分成一只只蚂蚁。现在和微服务有点关系。
6.管道架构? 例如过滤器,netty的消息处理
四、使用架构的目的
实现两个目标:
1.工程管理-例如微服务可以较大提升运维的压力
2.市场需求-在实现管理目标前提下,可以考虑由此产生的市场目标。 事实上不少框架是因为有市场需求才产生的。
软件框架,是典型地通过技术来实现管理目标的一个例子。软件架构对于工程管理的作用,基本等同于组织结构对于组织的作用。
一个合适的架构,能够满足特定目标,例如:
- 可靠性 -- 甲方必须的。甲乙方节省维护支出
- 可扩展性 -- 一般是乙方节省支出
- 可维护 -- 一般是乙方节省支出
但最终目的是:让甲方满意,让乙方赚钱(更快的实施速度、更地的运营成本)。
五、小结
一个项目需要采用什么架构,需要考虑的因素比较多:
- 商业目标
- 项目周期
- 甲方投入
- 项目组的能力
- 是否需要吹牛
- ....
从乙方的角度出发,如果不是做很大很复杂的项目,轻易不要采用微服务、云架构。
从管理者角度出发,且不可技术为向导,为技术而技术,永远要牢记--技术服务于商业,亏本的买卖不能做!
如果有人总是撺掇你在并发只有几千的项目中使用微服务,那么要好好考虑那人的目的了。
如果是出于增加团队的技能点,为将来的项目做准备,是可以适当考虑在1,2个宽松的项目中练手,但不要夸大化范围。