专栏首页CSDN技术头条软件架构发展历程分享

软件架构发展历程分享

架构的形式与特点

设计文档和代码

我们一般说的架构既包括架构的设计过程,也包括设计的产出物,一般可以包括各类设计文档、设计图,也可以包括一些技术验证代码、Demo 或者其他相关程序。文档的目的在于准确记录我们的思维产物,在软件尚未实现时,作为指导蓝图,尽量精确的描述清楚软件。

在软件的实现过程中,可能随时随着我们的深入研究,根据具体情况对文档做出局部的一些调整和修改。文档作为结项或交接的一部分,也是整个软件项目的产出物的一部分,成为公司 IT 资产的有机组成部分。

架构服务于业务

正如19世纪的伟大建筑师路易斯•沙利文(LouisSullivan)倡导的建筑设计著名格言:“功能决定形式(Form follows function)”,软件架构首先是要服务于业务功能的。

架构影响研发团队的组织形式

业务拆分的方法和技术框架的选择必然会影响到研发团队的组织形式。业务拆分的越细致,越有利于我们更好的对项目的各项指标量化计算,更精确的估计工时和成本,从而指导我们每个小组应该分配多少资源,使用什么样的协同和任务确认形式。

并且随着项目的推进,计划与实际情况之间的匹配程度也随时可以进一步精确调整,进而影响到我们应该对每一块任务的投入资源进行动态调整。

架构存在于每一个系统

每一个已经实现并运行的系统,都是特定架构设计的载体。有些系统对应的架构,有详细的设计文档来描述;有些系统的设计文档,残缺不全,甚至还因为在系统的发展变化的同时,文档没有更新,导致设计文档与实际系统不符;有些系统干脆就没有设计文档。但是这些系统,都是基于一定的架构来创建的。

每种架构都有特定的架构风格

每种架构方式,每个具体系统内所体现的架构设计,都是可以被工程师们理解,进而提炼出来一些架构思想和设计原则,这些思想和原则就是这种架构方式的风格。依据这些风格,我们可以将各种架构方式,进行分门别类,从而进一步讨论每种架构风格的特点。

架构需要不断的发展演进

随着计算机软硬件的不断发展,软件架构思想也在不断的发展变化。另一方面,软件为其提供业务处理和服务能力的每个具体行业领域也在不断发展变化,业务处理流程、参与角色、业务形式不断的推陈出新。

这就要求我们在系统架构设计时,保持终身学习的精神,持续吸收新思想新知识,保持贴近一线业务群体,随时因地制宜,调整架构设计,采取最适合当下场景的解决方案。

架构的目标与方法

明确软件系统架构的一些通用目标,可以使我们更明确如何考虑架构的方向;而了解架构的方法和方法论,则让我们可以知道从哪些角度可以比较全面的描述清楚一个系统的架构设计。

可控性与拆分

对于复杂问题的简化处理,一个简单办法就是分而治之。按一定的粒度把目标问题进行分解,可以非常有效的提升目标的可控性,使得目标变得更加可以量化、进而优化。

系统按照合适的粒度拆分成不同模块的过程,我们一般称为模块化。模块化也是软件工程化的基础。在这个基础上才能够实现分工合作。

复用性与抽象

复用性一直是软件设计领域的一个很重要的指标。复用的一个关键是我们对于现有具体问题的抽象,找到各种不同问题中存在的不变性,进而作为一种通用结构来统一处理。

拆成是把整体变成很多局部,再对局部分开对待和研究其性质。反过来,我们按照高内聚的指导思想把一些紧密联系的功能聚合后,打包成一个可以整体复用的部分,这就是组件,这个过程就是组件化。

通过组件化,我们可以得到抽象再组合出来很多业务组件。这样,在更大粒度上实现了功能的复用。

非功能性需求九维目标

(1)高性能

系统必须满足预期的性能目标,在并发用户数(Concurrent Users)、并发事务数(Transactions per Second,TPS)、吞吐量(Throughout)等指标方面达到预估值,支撑使用人群的正常使用操作。

(2)可靠性

业务系统直接影响到用户的经营和管理,因此必须是可靠的。

(3)稳定性

软件系统必须是能够在用户的使用周期内长期稳定运行的。这要求系统具有一定的容错能力。

(4)可用性

可用性是指系统在指定时间内的提供服务能力的概率值。我们一般采取集群、分布式等手段提升系统的可用性。高可用性是目前系统架构设计方面的一个热点。

(5)安全性

用户的业务数据是具有非常高的商业价值,如果被泄露或篡改将会带来重大损失。安全性是软件系统的一个重要的指标,也是架构设计的一个重要目标。

(6)灵活性

软件系统应该具备满足不同特点的用户群和目标市场的能力,更灵活。

(7)易用性

软件系统必须拥有较好的用户体验,便于用户使用。

(8)可扩展性

业务和技术都在不断的发展变化,软件系统需要随时根据变化扩展改造的能力。

(9)可维护性

软件系统的维护包括修复现有的错误,以及将新的需求和改进添加到已有系统。因此一个易于维护的系统对于用户提出的问题或改进,可以及时的实现高效的反馈和响应支持,同时有效降低维护成本。

基于这些目标,经常有人说:“架构是系统非功能性需求的解决办法的集合”。

作者说:

本文原文以架构发展历程为镜子,借鉴历史,以便更好的了解现在,迈向未来。

面向广大一线程序员、架构师、技术经理,我们从研发管理和技术管理等方面,阐述每种架构的传承与改进,结合背后的架构思想和设计逻辑的变迁,全部浓缩到这里:

  1. 理解什么是架构,模式、服务、组件、模块、框架、平台等概念及其关系,日常工作中更精确的使用这些概念表述自己的架构设计。
  2. 熟悉架构的目的、形式、方法,从而能够以全面的架构师思维,全面和科学地思考系统设计,结合自己的实践,逐步成为一名合格的架构师。
  3. 了解软件架构发展过程,从单体架构,到分层模式架构,集群架构,分布式架构、SOA 架构、微服务架构(MSA)等,能够深刻认识其中的架构思想。
  4. 掌握各种架构风格的特点和方式,以及实践过程中的优缺点,能够在具体的架构设计中灵活应用实践各种架构思想。

本文分享自微信公众号 - CSDN技术头条(CSDN_Tech)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-03-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 张升:农业银行的分布式架构应用实践与展望

    近年来,以阿里为代表的互联网企业提出的“去IOE”,在业界引起了广泛的讨论。“去IOE”直接含义是不使用传统IT巨头的产品,这些厂商产品虽然好,但基本处于市场垄...

    CSDN技术头条
  • 微服务与单一整体式架构的优劣浅析

    责编/钱曙光,关注架构和算法领域 开发者要么出于本能,要么很快就能在痛苦中发觉:即便一个很小的变化也能改变一切。就像攀岩那样,每次挪移都会影响到未来的抉择,因此...

    CSDN技术头条
  • 从点线面体谈开发到架构师的转型

    我工作十余年,从负责一个模块,到负责一个产品,再到负责整个支付平台的架构设计,包括业务架构、产品架构到应用架构,再到技术架构,是一个从点到面逐渐转型的过程,同样...

    CSDN技术头条
  • 《架构师》反思:软件架构设计

    最近在看《软件架构师教程》,今天就第五章《软件架构设计》总结一下,其中还有自己所联想到的。主要从以下几个方面来描述: 软件架构 ABSD 架构模式 DSSA...

    用户1172223
  • 面向对象架构设计流程

    软件架构:与"设计模式"类似,基于"领域架构",应用架构设计原则和方法,精雕细琢,逐步迭代,得出最终的软件架构。

    别明天就今天吧
  • 「架构技术专题」总结:共计7篇阐述架构技术之美

    详解架构中五个重要的核心指标:性能、可用性、伸缩性、扩展性和安全性。我们究竟如何把握?

    java进阶架构师
  • 神经架构搜索在视频理解中研究进展的综述

    作者 | Michael S. Ryoo 研究员与 AJ Piergiovanni 学生研究员(Google 机器人团队)

    AI科技大本营
  • 「解决方案架构」解决方案架构概述

    解决方案架构是定义和描述在特定解决方案上下文中交付的系统架构的实践,因此它可能包含对整个系统或仅其特定部分的描述。解决方案架构的定义通常由解决方案架构师领导。

    首席架构师智库
  • Lambda架构的质疑

    Nathan Marz 写了一篇非常受欢迎的博客文章,描述了 Lambda 架构(如何打破CAP定理)。Lambda 架构是一种在 MapReduce 和 St...

    smartsi
  • 阿里十年架构师用一张图告诉你什么是系统架构师作为架构师应该掌握哪些技术?

    这张图从架构师的综合能力、岗位认识、岗位职责等方面,清楚的画出了作为一个架构的基本准则。人人都想成为架构师,可作为架构你达到了上面的要求了吗?

    美的让人心动

扫码关注云+社区

领取腾讯云代金券