关闭

规划还是演化?我对架构影响的思考

【文章摘要】架构是客观存在的,不管我们是否有意识地考虑它。架构不是孤立存在的,它是在具体的上下文环境中,为达到明确的目标而存在的。架构不是“屠龙术”。

u=3952655824,3068178814&fm=21&gp=0

架构这个概念,和计算机科学(包括近几年才成为一级学科的软件工程)的其他术语类似,都是从传统学科借用来的。这是因为计算机科学太年轻、发展太快,来不及形成自己特有的术语和名词。因此,在学习和思考方法上,我常常推荐类比法,尝试用一些耳熟能详的事物去理解和解释计算机科学领域的概念,以求“老妪能懂”的效果。

644301125655332272

今天给大家分享的主要包括以下内容:

660801102678745472

这里介绍的一些内容,大多是个人在学习和实践过程中的一些思考和体会,还很不成体系,还有很多需要继续推敲的地方。我会在未来的工作实践中更加深入思考,广泛参考领域内的成果,力求概念准确,容易理解。也欢迎各位同行专家不吝赐教。

什么是架构?

关于架构概念的学习和理解,我建议从2个方面入手:

1、这个概念来自于建筑工程领域,要深入准确地理解,需要看一些建筑方面的资料,比如我会看梁思成《图像中国建筑史》手绘图,从中体会什么是架构;我也会到建筑工地去看建筑施工的一些情况;还会在旅游时有意识地关注不同样式的建筑,体会其架构的不同。“建筑是凝固的音乐”,我们要试图体会架构之美。

2、对于计算机科学与工程实践中总结出来的一些架构,我们要通过实践来学习和领会。比如对于MVC架构,我们是否联想到用VC++编程时“Document/View”模型?比如说到三层架构或者多层架构,我们是否考虑到与“Client/Server”二层架构的关系?

架构工作可能是隐式的

354695439536419530

架构工作,不管有没有架构师被指派,其实都是会做的,只是有些时候,架构工作被做了,但没有人意识到。

有明确的架构师,可能会使架构工作更加专业化,可能对提高架构的质量有帮助;但并不是只有架构师才可以做架构工作。

我们应该把架构师当成一种角色,而不仅仅是一个头衔、一个位子。也许有很多人的工作头衔是架构师,但其实际工作和架构关系不大,也可能有些人没有架构师头衔,但其在实际工作中为架构正在做贡献。

TOGAF的企业架构模型

434668250652453216

As shown in the figure, TOGAF divides an enterprise architecture into four categories, as follows:

1.Business architecture—Describes the processes the business uses to meet its goals

2.Application architecture—Describes how specific applications are designed and how they interact with each other

3.Data architecture—Describes how the enterprise datastores are organized and accessed

4.Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions

图中,TOGAF把企业架构分为4个部分:

  • 业务架构。描述业务流程及其达成的业务目标。
  • 应用架构。描述具体的应用系统的设计以及相互之间的关系。
  • 数据架构。描述企业的数据存储以及访问方式。
  • 技术架构。描述基础设施如何支持应用系统的运行及交互。

其中,一个重要的理念是业务架构与应用架构的映射关系(依赖、推理)。应用架构要基于业务架构来考虑,而不是凭空想象。应用是业务能力的提供者。

我们在这里重点关注数据。

34037513833641087

很多时候,IT部门、以及IT部门的一些人,常常把自己当成数据的所有者,导致认为地制造了藩篱,阻碍数据的共享及访问。其实,IT通常应该只是“司机”的角色。角色错位了,想做事正确?难于缘木求鱼。

这里强调数据,是因为数据是对客观世界的反映,而我们的每一个应用,不过是客观世界的一个视图。

数据是最基本的。数据可以被处理、解释而得到各种信息,而信息又可以被挖掘出有用的知识。我们也可以从中理解当今所谓DT的重要性,以及大数据时代,数据就像工业时代的石油一样重要。

架构的地位

113150703273016046

架构是客观存在的,不管我们是否有意识地考虑它。架构不是孤立存在的,它是在具体的上下文环境中,为达到明确的目标而存在的。架构不是“屠龙术”。

“规划-架构-设计”这三者是紧密联系的,常常被混为一体。为了理解这些概念的联系和区别,我们可以与市政规划进行类比。巴西利亚的建城史、华盛顿的城市规划,其理念值得我们在考虑架构时借鉴。

1、规划与架构

671989853288708129

这里把规划提取出来,而不是与架构混为一谈,是为了有助于理解思考与实践的不同阶段和步骤,帮助思维更加清晰。从软件工程与建筑工程的类比,更容易地理解架构和规划。另外,“自顶向下,逐步细化”的结构化思想也清晰可见。我们推崇面向对象的方法,因为它与客观世界的实际情况更接近,同时,我们也要继承和发扬结构化方法。

2、架构与设计

266302320859243658

所有的架构都是设计,但不是所有的设计都是架构。架构可以认为是宏观设计、顶层设计。

分布与集中

597776066843247939

计算模式经历了以下几个发展阶段:

1、主机-终端(mainframe)

2、个人计算机(PC)

3、客户机/服务器(C/S)

4、分布式计算(网格、云计算等)

我们选择什么的模式,一方面要跟上技术发展的趋势,另一方面要知道目的是什么。

如果规模不大,采用分布式部署意义不大。

解耦与服务化

905290302701809174

对解耦与服务化的关系进行深入思考,尝试理解其本质,明确什么是目的,什么是手段。在做决策的时候,就有助于分清主次。

下图展示一种不严格的解耦方法:

706032738561838040

  • 代码行,是度量程序规模和约束程序代码风格的常用维度。
  • 这里,考虑通过限制子程序代码行数来保证“单一职责”。

对于企业应用架构向“微”服务演化,解耦是基础。为此,在程序实现时,“单一职责”原则需要尊循。即使不走服务化道路,降低耦合度也是好的。

是否可以假定:一般情况下,对于特定的语言环境,比如:java和C#,较少的代码行很难实现多个业务功能?于是以子程序(函数,过程,方法)代码行数对工程师执行“单一职责”原则进行度量。

对于不同语言,建议对开发小组的代码行进行统计,经过一段时间的积累得出合适的经验值。一般地,这个代码行数的经验值是和小组的能力相关的。

迭代与敏捷

278145156223739841

敏捷方法的使用离不开迭代,我们需要合理地使用这两种方法,才能使我们的交付物越来越逼近用户的真实需求。

这里提到了用户的真实需求,我也多说几句。用户的需求不应该是我们作为BSA或者SME假设出来的,而是我们通过各种有效的方法,比如访谈,从用户那里捕获的。即使我们对用户的建议是正确的,帮助用户完善需求的,也一定要取得用户的完全理解并由用户正式确认。

服务化/分布式的网络基础

701925406729523874

无论服务化还是分布式,都需要进程间通讯(IPC),也包括线程间的通讯。这样,一个好的通讯协议是必要的。HTTP协议的设计初衷据说是为了人-机通讯,后来被用作机器间通讯(M2M),这是服务化/分布式的网络基础。

其他协议,也可以担此大任。只是从复杂性、使用难易程度、普遍性等方面要多加考虑。比如传统的web services,其SOAP协议除了可以基于HTTP,还可以基于 SMTP。

由分工引发的思考

632665471006011165

没有分工,协作就是一句空话。没有明确的分工,就会造成扯皮等现象。分工有助于提高效率和质量。要想分工,就要做好功能分解。而功能分解到合适的粒度,也可以认为是服务化的基础。

微服务所倡导的“单一职责”,其实质也是明确责任,消除歧义。简单即美,大道至简。单一职责恰恰符合这个原则。

从图中这个对制造别针的分工的描述,你会体会到并发现,很多基本道理是相通的,不论对于生产制造还是软件开发。这就是道法自然。

规划还是演变?

750361342184241545

演化这个词越来越流行了,但仔细想一想,有些情况演化的周期是很长的。就像不可降解的塑料制品,其以无害身份重新回归自然需要几百年甚至更长的时间。考虑演化时,也要结合软件/应用系统的生命周期,否则失去意义。

缺少规划则难于演化

589285696932475977

单靠演化,即使能使架构越来越优化,也可能需要很长的周期,而对于产品或者项目,时间这个约束条件往往是苛刻的。

如前面所阐述,迭代是有条件的。我的建议是:在有规划的基础上进行演化。我们无法得到普适的架构,但可以得到确定领域的通用架构,可以在特定领域通过演化使应用架构逐步优化,逐步与业务架构相适应,提高匹配度。

从架构角度解决企业应用痛点

681574087479889324

通过调研,我们发现企业应用系统面临的三个主要痛点:

1、灵活性差

2、交付时间长,动辄3个月或者半年乃至一年

3、性能差,用户体验不好

针对灵活性差,我们提出要降低耦合度,这也是软件工程中的一个基本原则。这样的问题,反映出我们的软件设计、开发水平不高的现实,专业性差。很多时候,很多开发人员还分不清程序和软件的区别,还只停留在功能实现的低水平上。这不单是靠架构优化能解决的,而是要靠提高整体开发水平来解决。

针对交付时间长,我们考虑从提高重用和构件化等方面着手,不断积累企业应用构件库。这好比我们烧砖建房,我们从实际需求出发,逐步建立并不断更新有限的砖块规格集合,未来所有的房屋都使用标准件来搭建。

针对性能问题,我们在构件化的基础上逐步地适度地服务化,这样讲是因为我们认为,不是所有的应用系统都适合服务化。有了这样的基础,我们对系统的扩展,包括水平和垂直,都会变得容易,分布式的部署水到渠成。

通过前面的痛点及解决方案的分析,我们总结了好的企业应用架构的三要素,同时也作为我们的三步走战略:

1、组件化/构件化

2、服务化

3、分布式环境

服务化是和多进程/多线程相关的,是减小应用部署粒度的过程。而分布式部署,其基础是进程/线程间的通信。要理解RPC,最好首先理解IPC,这个前面已有论述。

624215872698253737

企业应用系统服务化参考模型

445293431589575768

这是我们针对企业应用系统服务化而开发的模型,考虑了多种逻辑和物理架构。结合企业应用,基于多层分布式体系结构而进行的实例化。我们希望该模型能够覆盖企业的全部应用,包括基于package的二次开发系统(如SAP,Oracle),基于SaaS的云应用(如SFDC),以及基于Java/.Net自开发的一些应用。我们正在实践中逐步完善这个模型,希望能为企业架构的优化助力。

本文由

产品100

为你推荐并呈现

文章来源:微信公众号:聊聊构架(ID:archtime)

文章作者:李晓时

友情提示:

若出处标注错误,请联系QQ:2977686517及时更正,感谢理解和支持!

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表