从零开始学架构（二）架构知识领域

更新说明

本篇文章已经整理完很长时间，总感觉有些不足，因此一直没法，希望润色后再发，深感自己水平有限，迟迟没有动笔。但是收到多位朋友的邀约，思考再三决定逐步完成本系列文章。其中不足，请批评指正，我们一起进步。

内容摘要

主要从架构方法论，系统划分，架构原则，通用模式，架构视图，几个方面。整体上介绍了架构相关的知识领域，在此基础上，可以有目的的学习相关资料。

本篇主题 

2.1架构方法论：面向过程，面向对象，面向方面，面向服务

2.2系统划分：系统，子系统，模块，功能，接口

2.3架构基本原则：场景化，抽象， 通用专用，高内聚，松耦合 ，职责划分，关注点分离， 分层架构等

2.4模式：设计模式，架构模式，基础设施模式

2.5架构视图：4+1视图

一、架构方法论

在架构领域主要包括面向过程，面向对象，面向方面，面向组件，面向服务等方法论。每种方法关注的点有所不同。并伴随着软件工程和系统规模逐渐演化。具体使用哪种方式，需要根据实际场景，进行合理的技术选型。以下将综合介绍，主流编程方式的相关知识总结。

1.1面向过程（procedure-oriented programming ）

结构化编程思想的核心：功能分解（自顶向下，逐层细化）。将一个大的问题划分为几个小的问题，再将几个小的问题划分为更小的问题，我们解决大问题非常困难，但是解决划分后的最小的问题却比较容易。

面向过程编程把编程任务划分成一个一个的步骤，然后按照步骤分别去执行。其中每完成一个步骤就像是完成一个任务中的单个过程一样。

公式：程序=算法+数据结构

关注：流程，函数，库文件

优点：记账式代码，容易理解

缺点：与业务流程强耦合，复用性差

代表语言：basic，c

1.2面向对象（object-oriented programming）

面向对象编程（object-oriented programming）简称oop技术。面向过程编程常常会导致所有的代码都包含在几个模块中，使程序难以阅读和维护。在做一些修改时常常牵一动百，使以后的开发和维护难以为继。而使用oop技术，常常要使用许多代码模块，每个模块都只提供特定的功能，它们是彼此独立的，这样就增大了代码重用的几率，更加有利于软件的开发、维护和升级。

在面向对象中，算法与数据结构被看做是一个整体，称作对象，现实世界中任何类的对象都具有一定的属性和操作，也总能用数据结构与算法两者合一地来描述，所以可以用下面的等式来定义对象和程序：

对象=（算法+数据结构），程序=（对象+对象+……）

从上面的等式可以看出，程序就是许多对象在计算机中相继表现自己，而对象则是一个个程序实体。

面向对象编程思想的核心：一切皆对象，抽象，复用，提高灵活性

面向对象编程思想主要是复用性和灵活性（弹性）。复用性是面向对象编程的一个主要机制。灵活性主要是应对变化的特性，因为客户的需求是不断改变的，怎样适应客户需求的变化，这是软件设计灵活性或者说是弹性的问题。

公式：程序=对象+交互【对象=（算法+数据结构），程序=（对象+对象+……）】

关注：抽象，对象，类，继承，封装，多态

优点：复用性，扩展性，灵活性，维护性

缺点：对象化将简单的问题复杂化，不能解决公用横切代码问题

代表语言：java，c#

方法论：

ooa: object oriented analysis 面向对象分析方法

ood:object oriented design 面向对象设计

oop: object oriented programming 面向对象的程序开发

1.3面向组件（component-oriented programming）

面向对象支持重用，但是重用的单元很小，一般是类；而面向组件则不同，它可以重用多个类甚至一个程序（组件）。也就是说面向组件支持更大范围内的重用，开发效率更高。如果把面向对象比作重用零件，那么面向组件则是重用部件。

cop比oop更进一步。通常oop将数据对象组织到实体中。这种方法具有很多优点。但是，oop有一个大的限制：对象之间的相互依赖关系。去掉这个限制的一个好的想法就是组件。组件和一般对象之间的关键区别是组件是可以替代的。

公式：程序=组件+交互

关注点：功能模块

优点：将系统组件化设计，提高复用性

缺点：增加了组件维护和升级成本

代表框架：osgi

1.4面向方面（aspect-oriented programming）

将通用需求功能从不相关类之中分离出来；同时，能够使得很多类共享一个行为，一旦行为发生变化，不必修改很多类，只要修改这个行为就可以。

aop就是这种实现分散关注的编程方法，它将“关注”封装在“方面”中。

基本定义：将通用功能与业务逻辑分离

关注点：切面，通知，连接点，织入

实现技术：动态代理

代表框架：spring aop

1.5面向服务（service-oriented programming）

sop是一种体系结构，目标是在软件代理交互中获得松散耦合。一个服务是一个服务提供者为一个服务消费者获得其想要的最终结果的一个工作单元。服务者与消费者都以软件代理代表他们自己的角色。

    这听起来有些太抽象，但是sop确实无处不在。让我们在你的住房中找到一个sop的例子。例如播放一个cd,你可以将要播放的cd放入cd机中，cd机将为你播放这张cd，cd机提供了一个cd播放服务。这里的好处就是你可以用不同的cd机去播放同一张cd。他们能提供同样的cd播放服务，但是服务质量是不同的。

    sop的思想明显不同于面向对象的编程，面向对象编程强烈的建议你应该将数据与其操作绑定。因此在面向对象编程风格中，每张cd 有它自己的cd播放机，他们之间不能被拆开。这听起来很奇怪，但是这就是我们建立许多已存软件系统的方式。

而sop就不一样了，为了减少异构性、互操作性和不断改变的要求的问题，这样的体系结构应该提供平台来构建具有下列特征的应用程序服务：

松散耦合、位置透明、协议独立

    基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通信的特定服务，因为底层基础设施或服务“总线”将代表使用者做出适当的选择。基础设施对请求者隐藏了尽可能多的技术。特别地，来自不同实现技术（如 j2ee 或 .net）的技术规范不应该影响 sop用户。如果已经存在一个服务实现，我们就还应该重新考虑用一个“更好”的服务实现来代替，新的服务实现必须具有更好的服务质量。

公式：系统=服务+交互

关注点：服务化，业务拆分，独立部署，服务粒度

演变：rpc，服务框架，服务治理，微服务

优点：提供业务粒度的复用组件，可以有效利用资源提高性能

缺点：维护，部署成本高，需要自动化

代表框架：dubbo，zero ice，spring boot

二、系统拆分

要解决复杂系统的架构问题，在需求分析的基础上，要首先进行系统的拆分，将大系统拆分为小的系统，小的系统拆分为模块。采用分而治之的方式，进行系统架构设计。关于拆分的粒度与实际的项目和团队情况，有所差异。本节只介绍通用的系统拆分方法。

系统的拆分可以按照纵向和横向切分，纵向是指按照业务系统或功能模块进行拆分。横向是按照分层架构进行切分。

2.1垂直拆分（纵向）

纵向切分可分为：系统，子系统，模块，功能，接口

系统：

子系统：根据职责划分的，具有不同的业务意义切分的系统。比如用户子系统，订单子系统。

模块：实现某一个功能的集合，解决某一特定问题。比如会员模块。

功能：模块中的一个功能点，实现某种能力，比如会员注册功能。

接口：对外暴露，提供对外访问自身功能的能力。

纵向切分是从粗到细的过程，经过分析很好的定义了系统的功能分解结构。可根据分解结构，进行功能细化或项目预估。

2.2水平拆分（横向）

横向切分可按照物理或逻辑方式切分，物理切分是指将一个系统进行横向切分后的每一层或多层一起部署，每个部署实例代表一层或多层。比如接入层，服务层，资源层等。

逻辑切分是不考虑实际部署，从系统的逻辑角度出发进行分层。可分为表现层，业务层，资源整理层，资源层。具体的部署，可能是集中也可能是分开部署。

设计要点：每一层都有自己的边界，关注点和职责，上层依赖底层，避免跨层调用。

三、架构基本原则

架构设计，需要依据一些基本原则进行设计，在原则的基础上进行权衡，取舍，获得最终的架构决策。本节介绍，几种常用的架构原则。

场景化：每个需求都应该有适应的场景，基于场景进行设计，避免无目标或设计过渡。

抽象：将具体的事物，根据共性进行抽象，将公有行为抽象为接口，将共有逻辑抽象为基类。

高内聚：指部件的内部关系，将属于自己的属性，行为进行封装，对外暴露必要的接口。当内部改变时，不影响外部的使用。

松耦合：指部件之间的依赖关系，应该是弱依赖，而不是强依赖，可通过接口或异步实现解藕。

关注点/职责分离：将不同职责或关注点不同的进行拆分，使其只负责自己的事情，而不负责其他的事情。基本要求是分离不相关的，分离不稳定的。

分层架构：将系统进行物理层和逻辑层拆分，每层只关注自己负责的事情，并提供对外访问接口。分层可以将系统进行拆分，易于层级复用，代码维护性好，可根据工种分工。

通用专用：将通用部件和专用部件进行拆分，降低耦合度，提高复用性和可维护性。

平衡：没有最好的架构，只有更合适的架构，权衡需求，技术，约束，质量，成本等影响因素做出最好的决策。是架构师必须把握的第一方法论。

其他原则：solid

四、模式

模式是针对某一问题的通用解决方案，是前人智慧的结晶。通过应用模式，可以快速有效的找到最佳解决方案。系统架构中涉及三种模式，设计模式，架构模式，基础设施模式，分别解决代码结构，系统结构以及网络和硬件部署的问题。

4.1设计模式

解决的问题：代码设计层面，通用问题的通用解决方案。

模式分类：创建型（5），结构型（7），行为型（11）

创建型：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

模式汇总：借用一张图：出处（23种设计模式全解析）：https://www.cnblogs.com/geek6/p/3951677.html

 

4.2架构模式

解决的问题：确定系统中关键架构设计的架构和交互机制。

模式分类：

1、模块结构(from mud to structure)型。帮助架构师将系统合理划分，避免形成一个对象的海洋。 包括 layers （分层）模式、 blackboard （黑板）模式、 pipes/filters （管道/过滤器）模式等。

 

2、

分散系统（distributed systems）型。为分散式系统提供完整的架构设计，包 括像 broker（中介）模式等。

3、人机互动（interactive systems）型，支持包含有人机互动介面的系统的架构设计，例子包括 mvc（model-view-controller）模式、pac （presentation-abstraction-control）模式等。

 

4、

 adaptable systems 型， 支持应用系统适应技术的变化、 软件功能需求的变化。 如 reflection（反射）模式、microkernel（微核）模式等。

模式小结：此图出处（10种常见的软件架构模式）：https://www.cnblogs.com/icanfixit/p/7518146.html

 

4.3基础设施模式

解决的问题：硬件，网络等底层设计和基础架构问题。

模式分类：涉及硬件，网络，中间件，安全等方面。

可详见书籍《基础设施设计模式》

 五、架构视图

  架构视图是从不同的涉众看问题的角度出发，设计符合不同涉众需求的架构设计方案。用于全面，精确的分析和设计符合不同涉众要求的系统架构。业界使用比较多的是4+1视图。

 

5.1逻辑视图

逻辑架构的目的是职责的划分，并明确其与协作关系；其中职责的划分注意逻辑的分层、子系统以及关键类的定义；协作的定义关注接口的定义与协作关系的明确。

5.2开发视图

开发架构的目的是确定程序单元以及程序单元的组织结构；其中程序单元包括源文件、配置文件、程序库、框架、目标单元；程序单元组织包括project划分、project目录结构、编译依赖关系。

5.3数据视图

数据架构的目的是确定要存储的数据以及存储格式；其中存储的数据可以是文件、关系数据库、实时数据库；存储格式包括文件格式、数据库图表

5.4物理视图

物理架构的目的是确定物理节点和物理节点的拓扑结构；其中物理节点包括服务器、pc机、专用机、软件安装部署烧写以及系统软件的选型；拓扑结构明确物理节点的关系。

5.5运行视图

运行架构的目的是确定控制流和控制流的组织；其中控制流包括进程、线程、服务程序；控制流组织包括系统的启动与停机、控制流通讯、同步与加锁。

六、扩展知识

本部门内容可自行学习了解。

6.1插件架构和开发

6.2微服务架构

6.3uml建模

七、本篇总结

主要从架构方法论，系统划分，架构原则，通用模式，架构视图，几个方面。整体上介绍了架构相关的知识领域，在此基础上，可以有目的的学习相关资料。

八、参考资料

从面向过程到面向对象:http://blog.csdn.net/hjf19790118/article/details/6919578

面向对象编程（oop）、面向组件编程（cop）、面向方面编程（aop）和面向服务编程（sop）:http://blog.csdn.net/ocean181/article/details/6720371

面向对象，面向组件，面向接口，面向方面，面向服务编程的一些比较

http://chunniux.blog.163.com/blog/static/148497192012012101549604/

面向对象程序设计与面向过程程序设计解析

http://blog.csdn.net/tianfeng701/article/details/8040304

软件架构设计-五视图方法论:https://blog.csdn.net/nnsword/article/details/78109126

软件架构设计-五视图方法论:https://www.cnblogs.com/hongbo819/p/4871412.html

九、下篇预告

第三篇 uml建模

3.1架构模型

3.2静态模型

3.3动态模型

3.4建模案例