zoukankan      html  css  js  c++  java
  • 我的架构观-架构未来的发展

    最近看了一些架构方面的帖子,包括京东的、支付宝的,加上之前各种微服务,大平台,弹性化等各种架构词汇,在大脑里相互冲撞,一时间感觉不知所云,思维被各种概念牵引着,有点慌乱。当然这不是我想要的状态,于是运用曾文正公的处世之道:“立足当下,化繁为简”。回到架构的三个哲学问题:1.何为架构?2.它从哪里来?3.它要到哪里去?回答了这三个问题,就应该能抓住架构的本质,不至于人云亦云。当然,这只是一家之言,如果说错了,希望能指正我。

    1. 何为架构:与我而言,所谓架构其实是事物与事物之间恰当的关系。这个概念比较大, 我们不妨缩小一点范围就focus在IT架构领域。我们知道,TOGAF将架构分为业务架构、数据架构、应用架构、技术架构,这四个架构定义从不同的层面和维度解释了要实现上层企业架构应该具备的架构能力,这里的业务架构是从业务的维度讲业务流程、企业组织以及组织下的人员之间的关系;数据架构是从数据维度讲企业的数据资产及信息间的结构关系;应用架构是从应用系统的维度讲应用系统相互间如何协作以提供服务从而满足业务流程的系统化(也是讲系统间的关系);技术架构是从软硬件基础设施维度讲它们之间如何组合以提供基本的运算、存储、网络能力。
      • 当然,对于更一般的架构的认识,或许我们叫它系统架构或软件架构,指的是定义系统结构、行为、视图的概念模型的组织结构,包括系统分解的组成部分,它们的关联性,交互,机制和指导原则。定义比较晦涩,说的直白一点,还是从不同维度看各种能力及其它们之间如何协作以实现该维度的目标。进一步解释一下,我们通常说系统架构包括逻辑架构、物理架构、开发架构、运行架构、数据架构5个部分。所谓逻辑架构是功能模块如何划分,功能模块是啥,满足功能的能力嘛,如何划分其实还是在将关系嘛。再看物理架构,讲的就是物理服务器如何分配以及部署关系,其本质还是在讲能力和能力间的协作关系。其他三个架构也是在各自维度讲能力及关系。一般来说,系统需要的能力其实就是三种:1面向最终用户的支撑能力、2面向外部系统的交互能力、3面向数据的处理能力。所以说,架构本质就是这三种能力以及提供提供能力的实体相互间的关系。
    2. 它从哪里来:从架构的本质可以看到,在不同的维度架构需要提供不同的能力和关系,那是不是可以试着从这个角度看架构的发展过程呢?顺便也验证一下我们对架构的本质是否认知准确。我们知道,系统架构过程大致可以分为三个阶段:
      •   第一阶段是早期系统竖井式的架构,应用和数据交织在一起,无论是从逻辑上还是从物理部署上都是,因为这个时候各维度对能力的需要不是那么强烈,没有明显的能力短板,不需要明确区分相互间的关系。但随着系统壮大复杂,来自硬件的能力以不足以支撑整个维度需要的能力,这就进入第二阶段。
      • 基于SOA的分布式架构,通过SOA把这种能力水平拆分,好处当然是使得能力可以灵活增减,坏处是这种拆分会给能力间的关系增加复杂度,举例来说,原来通过内部调用即可满足的关系由于SOA把能力拆分,现在需要通过网络调用才能满足。那么当这种关系复杂度给系统间带来协作障碍时,我们就需要进入第三阶段。
      • 第三阶段即微服务+大平台架构阶段,通过构件大平台来控制这些复杂的关系,不要让其暴露出去变成不可控的因素。此阶段即把业务逻辑分散在微服务中,把所有业务处理中需要的技术能力统一归置到平台进行管理,平台通过标注化的,约定熟成的协议及通讯方式为上层的微服务们提供固定的服务,并把所有与服务安全、可靠性、监控、服务治理等相关的工作作为平台基础的能力提供出来。因此这种大平台其实就是通过设定标准和规范来降低关系的复杂度,是通过引入另外的能力和关系来达到的,比如大平台的引入本身就带来了更为复杂的关系。就像马路上的红路灯,虽然通过红灯停绿灯行等规范来解决交通拥堵的问题,但难道它们就不是造成更大拥堵的原因吗?
    3. 它要到哪里去:回答这个问题其实就是回答架构的下一阶段,我不是预言家,只是沿着我个人理解的架构发展路线来估测一下。从上面分析的架构路线来看,我们已经通过引入额外的标准规范一定程度上缓解了能力关系的复杂性,只不过这种引入带来了一定程度上大平台自身的能力挑战,因此我们可以预见,当需要大平台提供更加强的能力以满足更复杂关系的管理时,是不是在某一时点上平台自身的能力关系也变得不可控呢?就像马路上的红绿灯,想象一下当红绿灯出现故障时,路况是不是会更加崩溃呢?所以我们回过头来,还是从IT系统的起源来看,系统是服务于业务的,这一点毋庸置疑,因此架构的发展趋势一定也是让业务实现更自由,这种自由其实就是要有载体来负责管理这些关系性,而上面的分析我们发现通过引入外部的能力并非长久之计,那么很自然我们会想到最终的服务器会是这些载体,即将所有与技术相关的成本如协议、调度、服务、通讯、监控、缓存、服务调度等关系都最终龟缩成服务器硬件的基本功能,就像CPU、网络、存储能力一样,这种龟缩不一定完全有硬件服务器厂商来做,可以在驱动层、操作系统层、甚至在操作系统上再抽象出一层,通过这种内置的固化能力关系管理,使得各个维度上的能力真正做到可以按需使用,动态扩展。
        也许,架构的未来是没有架构!





  • 相关阅读:
    三列自适应等高且中列宽度自适
    两列高度自适应(转)
    Transform 1
    跟我一起透彻理解template模板模式
    走进C++程序世界-----operator new delete 重载
    linux下maven的安装
    JavaScript权威指南第01章 JavaScript 概述
    切勿辜负青春一场
    C++ 模板应用 实现一个Queue 队列
    从头认识java-14.4 Java提供的数组的有用功能(2)
  • 原文地址:https://www.cnblogs.com/dimmacro/p/4470935.html
Copyright © 2011-2022 走看看