架构和设计模式相关

摘自设计模式书籍

设计模式所倡导的原则：
开闭原则：一个软件实体应该相对开放，对修改关闭。在设计一个模块时，应当使这个模块可以在不被修改的情况下被扩展。关键在于抽象，抽象层要预见所有可能的扩展，因此，抽象层在任何扩展情况下都不会改变，即对修改关闭。同时，由于从抽象层导出一个或多个新类，可以有不同的实现，此即开放。简而言之，抽象层对修改关闭，通过扩展实现系统行为。
里氏代换原则：任何基类可以出现的地方，子类一定可以出现。
依赖原则：要依赖于抽象而不是具体实现。也就是说要针对接口编程，不要针对实现编程。
接口分离原则：应当为客户端提供尽量小的单独的接口，而不是提供大的接口。
组合复用原则：要尽量使用组合，而不是继承关系达到复用的目的。
迪米特法则：又叫最少知识法则。就是一个对象应当对其他对象有尽可能少的了解。

软件体系结构
以组件和组件交互的方式定义系统，说明需求和成品系统间的对应关系，描述系统级别的可伸缩性、能力、吞吐量、一致性和兼容性等属性。软件体系结构 由组件、连接件和属性组成。

SOA:面向服务的架构。包括几个层次：

1服务注册层（如UDDI）

2业务流程层（如WS_BPEL）

3服务层

4服务描述层（如WSDL）

5服务通信协议层（如SOAP）

6底层传输层（如HTTP, JMS, SMTP）

软件体系结构风格
描述一类体系结构
独立于实际问题，强调了软件系统中通用的组织结构
在实践中被多次设计、应用
是若干设计思想的综合
具有已经被熟知的特性，并且可以复用

系统架构风险：架构设计中潜在的、存在问题的架构决策带来的隐患
敏感点：为了实现某种特定的质量属性，一个或多个系统组件所具有的特性
权衡点：影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性

4+1视图方法

逻辑视图（logical view）对应uml中的类图

开发视图（development view）又叫implementation view？

处理视图（process view）又叫进程视图？可执行线程和进程作为活动类的建模，是逻辑视图的一次执行实例，描绘了所设计的并发与同步结构。

物理视图（physical view）又叫部署视图（deployment view），对应uml中部署图

场景视图（scenarios）对应uml中用例图

 

uml图例

类图  描述类、类的特性及类之间的关系

对象图  描述一个时间点上系统中各个对象的一个快照

复合构件图

构件图

部署图

包图  描述编译时的层次结构

用例图  描述各种参与者（用户和其他系统）和本系统之间的主要交互，同时描述利益相关者（例如用户和维护人员）所看到的系统行为。

活动图  描述过程行为和并行行为，显示了系统中从活动到活动的流，强调对象之间的控制流。

状态机图  描述事件如何改变对象的生命周期

顺序图（时序图）  描述对象间的交互，重点在顺序上

通信图  描述对象间的交互，重点在连接上

定时图

交互图  顺序图和协作图的统称。顺序图强调消息的时间次序，协作图强调收发消息的对象的结构组织。

顺序图：

协作图：

 

制品图

----------------------

检测技术实现方式：

1、结果返回值检测；2、运行超时检测；3、状态标志位检测

需求调研阶段常用方法：1.调查问卷；2.访谈；3.原型演示；4.JRP(Joint Requirements Planning)即需求收集联合讨论会会；5.各种通信手段交流；。。。

软件需求说明书 SRS(Software Requirements Specification)

背景，目标，任务概述，作用范围，应用对象，假定和约束，需求规定等等。

需求分析建模中用到的分层数据流图（DFD）

数据流图关心的是数据流、数据储存、变换/加工。不关心流程控制（流程图所关心）。

组件建模：即为系统划分子系统、模块和组件，为其建立层次结构和分配需求和职责。

服务建模：将应用程序定义为一组位于外部边界、架构层之间的抽象服务接口，并且提供通用的应用程序和基础结构。

 

web应用系统提高性能缓存技术：1、数据库连接池；2、分布式对象池；3、线程池。

企业集成总线（ESB)

主要功能：

1应用程序的位置透明性

2服务、消息路由

3传输协议转换

4消息格式转换

5消息增强

6安全支持

7监控和配置管理（系统配置管理和服务配置管理）。

集成方式倾向：

如果需要共享系统功能，应采用面向服务方式进行功能集成，可以跨硬件、跨OS平台、跨编程语言。

如果需要在通信协议和数据格式间交换，应该采用基于消息总线，以协议及数据适配器的方式实现灵活的通讯协议和数格式转换。

如果需要考虑各种工具间的协作关系，应该引入工作流程定义语言及引擎来动态描述工具间的协作关系。

如果有现成的第三方工具，可以考虑界面集成，可以绕过其内部复杂的处理逻辑。

 

微服务架构（Microservice Architecture）

旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

SOA和微服务的区别

1、SOA喜欢重用，微服务喜欢重写

SOA的主要目的是为了企业各个系统更加容易地融合在一起。 说到SOA不得不说ESB(EnterpriseService Bus)。 ESB是什么? 可以把ESB想象成一个连接所有企业级服务的脚手架。

通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。 它还可以把一个服务

路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。 它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成SOAP协议。 各服务间可能有

复杂的依赖关系。

微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，

把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然 后单独布署。 它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，

而是减少客户端和服务间的往来。API gateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。

2、SOA喜欢水平服务，微服务喜欢垂直服务

SOA设计喜欢给服务分层(如Service Layers模式)。 我们常常见到一个Entity服务层的设计，美其名曰Data Access Layer。 这种设计要求所有的服务都通过这个Entity服务层

来获取数据。 这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。 而每个微服务通常有它自己独立的data store。 我们在拆分数据库时可以适当的做些

去范式化(denormalization)，让它不需要依赖其他服务的数据。

微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。 类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。 在SOA设计模式中这种情况通常会用到

Multi-ChannelEndpoint的模式返回一个大而全的结果兼顾到所有的客户端的需求。

3、SOA喜欢自上而下，微服务喜欢自下而上

SOA架构在设计开始时会先定义好服务合同(service contract)。 它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，schema，等等。 它使用Enterprise

Inventory和Service Composition等方法来集中管理服务。 SOA架构通常会预先把每个模块服务接口都定义好。 模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。

SOA架构适用于TOGAF之类的架构方法论。

微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。