浅谈架构

  1. 云栖社区>
  2. 博客>
  3. 正文

浅谈架构

技术小美 2017-11-15 15:07:00 浏览1012
展开阅读全文

今天@Laruence 挖了个坑,我试着来灌点水。纯粹个人观点,不准确也不周密。

 
架构 (architecture) 这个概念确实不好定义。首先,它很虚,不像代码可以用源文件“自证”。其次,它很泛,好像跟什么都相关,开发、测试、部署甚至运营等各阶段都有其影子。然后,它好像还在变,在计算机发展的各个阶段(Mainframe/PC/Cloud)都感觉不太一样。而且,在不同的领域也都有不同的反映。
 
所以,一千个人心中有一千个哈姆雷特,一千个工程师眼里也能有一千种架构。在2012年2月1日晚11点左右(向Pkubuntu致敬),我的看法可以用两个例子说明。以建筑为例,设计师想方案,建筑师出图纸,工人施工同时项目管理贯穿始终,那图纸就是架构。如果说到烤鸭,骨头和肉是代码,鸭架子就是架构,而过程管理将其变成烤鸭。
 
如果要更正式点定义,架构就是model和pattern,从而把code串成system。而其中最重要的就是design principles (设计原则),即为什么这个问题要用这个而非那个。更文艺点,再结合点美学,也可以叫作design philosophy (设计哲学或理念)。
 
然后我们来看什么是model和pattern,这两个具体的定义我还没想出来。先说一下比较,model偏宏观,而pattern偏微观;model重抽象描述,而pattern重具体实现。比如,你的系统有一个服务端和一个客户端,那么client/server就是model,而client与server之间的交互方式则是pattern,比如RPC/message、同步/异步,比如用滑动窗口来组织请求与应答等等。当然,这和系统的尺度有关。如果你zoom in到服务端,此时的model可能就是模块的组织关系,而pattern则是调用方式,比如用function call还是event等。
 
具体到领域上,我觉得主要有三类架构问题(不包括硬件):
 
1. 软件架构,其典型用例是企业级软件,通过合理的功能抽象,提取出公共组件和通用流程,进行最大化的功能复用 (reuse)。我称其为软件的可维护性问题。
2. 系统架构,其巅峰是OS,重点是解决资源的分配与复用 (multiplexing)。
3. 大规模分布式架构,主要应用在Cloud中,重点是大规模系统的资源整合、快速交付和运维问题。
 
1有《Design Patterns》一书,2有很多OS、并行程序设计的书可供参考 (或者应该写本《Parallel Patterns》?),3目前我还不知道有什么书可参考。
 
那为什么架构会很泛又多变呢?这就牵扯到开发过程了。我们再引入一个方法论 (methodology) 的概念。传统软件工程那一套不必说了,互联网服务常用迭代式的开发方法 (现在又叫敏捷),这就是方法论。我个人的做法通常有三种:divide and conquer,modeling and iterate,back-of-envelop-calculation and simulation,按问题的规模、难易程度、熟悉程度、项目的组织方式等等选择不同做法。这就又提到架构师这个角色了,找时间再谈。
 
总而言之,相对于代码和功能这些更实际的东西,以上所说的都是偏虚偏抽象的事情,我称其为开发工艺问题,包括架构和方法论两个层面。不同时代的系统,其组成不同,对开发工艺的要求也不同。在Cloud时代,可归结为三点:软件架构和开发过程支持快速迭代,系统架构与分布式架构支持大规模用户和数据分析,然后由数据分析驱动迭代。
 
                                                                 ——林仕鼎
 

【本文首发于:林仕鼎新浪轻微博http://qing.weibo.com/2244218960/85c4105033000bwp.html











本文转自百度技术51CTO博客,原文链接:http://blog.51cto.com/baidutech/770958,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小美
+ 关注