主页

索引

模块索引

搜索页面

常用

重要

架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。

重要

目标：形成了自己的一套架构设计方法论。架构设计的思维和程序设计的思维差异很大。做架构师最好是精通一个领域，熟悉其他领域。

备注

架构既可做动词也可做名词，作为动词就代表系统的设计，作为名词就代表系统的表现形式。通常 “架构” 还是用作名词，动词就用 “架构设计”。

目标:

1. 清楚地理解架构设计相关的概念、本质、目的
    避免架构师在实践过程中把握不住重点、分不清主次，眉毛胡子一把抓，导致架构设计变形或者 “四不像” 。
2. 掌握通用的架构设计原则
    无论是何种业务或技术，架构师在判断和选择的时候有一套方法论可以参考，避免架构设计举棋不定，或者拍脑袋式设计。
3. 掌握标准的架构设计流程
    即使是刚开始做架构设计的新手，也能够按照步骤一步一步设计出合适的架构，避免某些步骤缺失导致错误的架构设计。
4. 深入理解已有的架构模式
    做到能够根据架构特点快速挑选合适的模式完成架构设计，或者在已有的模式上进行创新，或者将已有的模式组合出新的架构。
5. 掌握架构演进和开源系统使用的一些技巧

知行合一:

1. 亲自负责一个系统的架构设计，这种机会最锻炼人
    但不可能一个工程师从来没做过架构设计然后某天突然被委以重任，
    必须要先有一定的积累才会有这样的机会；
2. 参与某个系统的架构设计，在总架构师的指导下，负责其中一部分的设计
3. 在设计好的架构下进行开发
    虽然没有亲自参与架构设计，但如果能理解和看懂架构设计，对开发本身也很有帮助，
    如果能看出和分析出架构存在的问题，那就是一个展现自己的机会。

概念

系统&子系统:

定义:
  1. 【系统】泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。
  2. 【子系统】也是由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。

系统:
  它的意思是 “总体” “整体” 或 “联盟”。
  关键内容:
    a. 关联: 由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统
    b. 规则: 系统内的个体需要按照指定的规则运作，而不是单个个体各自为政
    c. 能力: 系统能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力

子系统:
  子系统的定义和系统定义是一样的，只是观察的角度有差异，一个系统可能是另外一个更大系统的子系统。

模块与组件:

两者容易混淆, 如:
  MySQL 模块主要负责存储数据，而 ElasticSearch 模块主要负责数据搜索
  我们有安全加密组件、有审核组件

定义:
1. 【软件模块(Module)】是一套一致而互相有紧密关连的软件组织。
  它分别包含了程序和数据结构两部分。
  现代软件开发往往利用模块作为合成的单位。
  模块的接口表达了由该模块提供的功能和调用它时所需的元素。
  模块是可能分开被编写的单位。
  这使它们可再用和允许人员同时协作、编写及研究不同的模块。
2. 【软件组件(Component)】定义为自包含的、可编程的、可重用的、与语言无关的软件单元，
  软件组件可以很容易被用于组装应用程序中。

模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已:
    从逻辑的角度来拆分系统后，得到的单元就是 “模块”；
    从物理的角度来拆分系统后，得到的单元就是 “组件”。

    划分模块的主要目的是职责分离；
    划分组件的主要目的是单元复用。

    注：“组件” 的英文 component 也可翻译成中文的 “零件” 一词，
      “零件” 更容易理解一些，“零件” 是一个物理的概念，并且具备 “独立且可替换” 的特点。

例:
  一个学生信息管理系统:
  从逻辑的角度来拆分，可以分为 “登录注册模块”“个人信息模块”“个人成绩模块”；
  从物理的角度来拆分，可以拆分为 Nginx、Web 服务器、MySQL。

框架与架构:

定义:
  1. 【软件框架 Software framework】是:
      a. 指为了实现某个业界标准或完成特定基本任务的软件组件规范，
      b. 也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
  2. 【软件架构 Software Architecture】是:
    软件系统的 『基础结构』，创造这些『基础结构』的准则，以及对这些结构的描述
    关键在 “基础结构” 这个概念并没有明确说是从什么角度来分解的
    采用不同的角度或者维度，可以将系统划分为不同的结构
    如:
      a. 从业务逻辑的角度分解，“学生管理系统” 的架构是: 登录模块、个人信息模块、个人成绩模块
      b. 从物理部署的角度分解，“学生管理系统” 的架构是: Nginx、Web 服务器、MySQL
      c. 从开发规范的角度分解，“学生管理系统” 的架构是: MVC 架构

软件框架-2个关键部分:
  a. 框架: 是开发的规范，如: MVC, J2EE, MVVM, MVP
  b. 框架: 是提供基础功能的产品，如: Spring MVC等

定义的角度来看:
  框架关注的是 “规范”，架构关注的是 “结构”。
  框架的英文是 Framework，架构的英文是 Architecture

An architecture is the the abstract design concept of an application.
  Basically, a structure of the moving parts and how they're connected.
A framework is a pre-built general or special purpose architecture
  that's designed to be extended.
If an architecture is the design of a structure,
  a framework is the architecture of a foundation.
Frameworks are specifically designed to be built on or extended.

重要

『软件架构』的重新定义: 软件架构指软件系统的顶层结构。这个看似简单的定义，包含的信息很丰富，基本上把系统、子系统、模块、组件、架构等概念都串起来了。1. 明确系统包含哪些 “个体”; 2. 明确个体运作和协作的规则; 3. “顶层结构”可以更好地区分系统和子系统

备注

框架是规范也是约束，可以理解为封闭性的话题，定义好，让别人如何去使用。而架构是一种结构，是一种开放性的话题，如何去设计组织架构，如何让架构更具有拓展性，减少沟通错误成本

趣味讲架构

搬砖 VS 软件开发:

搬砖的：“头，我们要造什么？”；（做什么系统？）
工程师：“龙之梦商城”；（XXX 系统，比如微博系统）
搬砖的：“图纸画出来了嘛？”；（架构是怎么设计的？）
工程师：“一楼主要以女性消费为主体、二楼以大众娱乐为主体、三楼以美食为主体”；
    （相当于微博系统中的各个子系统，比如评论子系统、动态子系统、消息子系统）
搬砖的：“头，说人话”；
工程师：“一楼有卖衣服、化妆品的，二楼有唱歌、看电影的，三楼有吃的”；
  （【模块】按照逻辑区分，比如存储数据模块、搜索模块、消息推送模块）
搬砖的：“有没有很知名的店啊？”；
工程师：“有的，一楼有香奈儿、优衣库...、二楼有好乐迪、万达影院....、三楼有海底捞、避风塘.....”；
  （【组件】按照物理区分，存储数据模块对应 Mysql、搜索模块对应 ElasticSearch、 消息推送模块对应 Kafka）
搬砖的：“对了，头，商城大门有啥需要叮嘱的施工规范不？或有啥简化施工工艺的新技术嘛？”；（有框架的可以用吗？）
工程师猛吸了一口烟，把烟头扔在地上，用皮鞋左右撵了两下，缓缓从嘴里崩出四个字。
  “老样子吧”。（Spring 全家桶甩起来）

银弹

备注

在古代的狼人传说中，只有用银质子弹（银弹）才能制服这些异常凶残的怪兽。在软件开发活动中，“银弹” 特指人们渴望找到用于制服软件项目这头难缠的 “怪兽” 的 “万能钥匙”。

软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。从 IT 技术的发展历程来看，先辈们在上述不同的环节中提出过很多在当时看来很先进的方法与理念。但是，这些方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点：我们可以通过诸多方式去接近 “银弹”，但很遗憾，软件活动中没有 “银弹”。 软件设计过程中，模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的 “拆分” 方法论，软件架构是一种对软件的 “组织” 方法论。一分一合，其目的是为了软件研发过程中的成本、进度、质量得到有效控制。但是，一个成功的软件设计是要适应并满足业务需求，同时不断 “演化” 的。设计需要根据业务的变化、技术的发展不断进行 “演进”，这就决定了这是一个动态活动，出现新问题，解决新问题，没有所谓的 “一招鲜”。 软件开发最本质的挑战有两个：复杂和变更，而软件的价值是保证业务的响应力，而与之相对的是开发资源的有限，而各种的软件开发方法论，也都是在研究有限的资源下，如何应对着两个挑战，寻找平衡点，实现业务目标，因为是在寻找平衡点，就说明是有取舍的，所以就没有所谓的银弹的存在

“No Silver Bullet” 的原文是：“没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。” 之所以这样说，是因为软件的根本困难（Essence，包括复杂度、一致性、可变性、不可见性) 复杂度：规模上，软件实体可能比任何由人类创造的其他实体更复杂，因为没有任何两个软 件部分是相同的 一致性：软件的变化必须遵循一系列接口标准规范，有些情况下它的变化就是要兼容； 可变性：一般有如下几种情况:

1. 当客户喜欢用某个功能或者某个功能能解决他的某些问题时，他会针对这方面提出很多优化该功能的需求点
2. 硬件或者其他配件的升级变化 必须升级现有软件平台

不可见性：软件不存在一种空间形态 可以通过一张图 或者其他载体来可视化展示，不能通过地图 电路设计图等来全面展示. 由于这几个点的变化，导致系统越来越臃肿，从而导致管理成本上升，沟通困难，可靠性逐年下降等等；而结构化 面向对象等主要是来提高生产率 可靠性和简洁性

设计模式就是面向对象的类和接口设计方法

参考

主页

索引

模块索引

搜索页面