最近看了一些架构方面的帖子,包括京东的、支付宝的,加上之前各种微服务,大平台,弹性化等各种架构词汇,在大脑里相互冲撞,一时间感觉不知所云,思维被各种概念牵引着,有点慌乱。当然这不是我想要的状态,于是运用曾文正公的处世之道:“立足当下,化繁为简”。回到架构的三个哲学问题:1.何为架构?2.它从哪里来?3.它要到哪里去?回答了这三个问题,就应该能抓住架构的本质,不至于人云亦云。当然,这只是一家之言,如果说错了,希望能指正我。
- 何为架构:与我而言,所谓架构其实是事物与事物之间恰当的关系。这个概念比较大, 我们不妨缩小一点范围就focus在IT架构领域。我们知道,TOGAF将架构分为业务架构、数据架构、应用架构、技术架构,这四个架构定义从不同的层面和维度解释了要实现上层企业架构应该具备的架构能力,这里的业务架构是从业务的维度讲业务流程、企业组织以及组织下的人员之间的关系;数据架构是从数据维度讲企业的数据资产及信息间的结构关系;应用架构是从应用系统的维度讲应用系统相互间如何协作以提供服务从而满足业务流程的系统化(也是讲系统间的关系);技术架构是从软硬件基础设施维度讲它们之间如何组合以提供基本的运算、存储、网络能力。
- 当然,对于更一般的架构的认识,或许我们叫它系统架构或软件架构,指的是定义系统结构、行为、视图的概念模型的组织结构,包括系统分解的组成部分,它们的关联性,交互,机制和指导原则。定义比较晦涩,说的直白一点,还是从不同维度看各种能力及其它们之间如何协作以实现该维度的目标。进一步解释一下,我们通常说系统架构包括逻辑架构、物理架构、开发架构、运行架构、数据架构5个部分。所谓逻辑架构是功能模块如何划分,功能模块是啥,满足功能的能力嘛,如何划分其实还是在将关系嘛。再看物理架构,讲的就是物理服务器如何分配以及部署关系,其本质还是在讲能力和能力间的协作关系。其他三个架构也是在各自维度讲能力及关系。一般来说,系统需要的能力其实就是三种:1面向最终用户的支撑能力、2面向外部系统的交互能力、3面向数据的处理能力。所以说,架构本质就是这三种能力以及提供提供能力的实体相互间的关系。
- 第一阶段是早期系统竖井式的架构,应用和数据交织在一起,无论是从逻辑上还是从物理部署上都是,因为这个时候各维度对能力的需要不是那么强烈,没有明显的能力短板,不需要明确区分相互间的关系。但随着系统壮大复杂,来自硬件的能力以不足以支撑整个维度需要的能力,这就进入第二阶段。
- 基于SOA的分布式架构,通过SOA把这种能力水平拆分,好处当然是使得能力可以灵活增减,坏处是这种拆分会给能力间的关系增加复杂度,举例来说,原来通过内部调用即可满足的关系由于SOA把能力拆分,现在需要通过网络调用才能满足。那么当这种关系复杂度给系统间带来协作障碍时,我们就需要进入第三阶段。
- 第三阶段即微服务+大平台架构阶段,通过构件大平台来控制这些复杂的关系,不要让其暴露出去变成不可控的因素。此阶段即把业务逻辑分散在微服务中,把所有业务处理中需要的技术能力统一归置到平台进行管理,平台通过标注化的,约定熟成的协议及通讯方式为上层的微服务们提供固定的服务,并把所有与服务安全、可靠性、监控、服务治理等相关的工作作为平台基础的能力提供出来。因此这种大平台其实就是通过设定标准和规范来降低关系的复杂度,是通过引入另外的能力和关系来达到的,比如大平台的引入本身就带来了更为复杂的关系。就像马路上的红路灯,虽然通过红灯停绿灯行等规范来解决交通拥堵的问题,但难道它们就不是造成更大拥堵的原因吗?
也许,架构的未来是没有架构!