架构设计基础-软件架构设计学习次日（非原创）

文章大纲

1、架构需求分析
2、架构愿景分析
3、架构设计原则
4、必备设计-API网关
5、参考文章

 

1、架构需求分析

1. 需求收集与分析

需求分析的前期工做是愿景描述及愿景分析, 即愿景分析就是需求的前期调研.
从软件过程来看，需求分析是一个承上启下的阶段–“上承”愿景，“下接”设计。需求分析的工做内容包含以下三方面：
1.1 需求捕获: 理解沟通
需求捕获: 从各个方面收集需求, 并理解需求.典型的需求捕获是使用“需求采集卡”：需求描述、需求提出者、需求记录者、需求类型等。

1.2 需求分析:作什么,有哪些问题
需求分析:需求捕得到到的是“原始需求”，而需求分析则对各方面收集到的需求进行分析、整理、概括、论证造成明确的需求。好比, 产品经理说,如今系统不稳定, 须要重构架构保证系统稳定. 这只是一个愿景, 咱们须要把这个需求造成一个明确的需求: 可行性99.99%, 要完成这个指标,须要作哪些工做.

1.3 系统分析:缘由是什么, 怎么作
三者不是独立无关的阶段，而是相互伴随、交叉进行的。

2. 需求分类

需求可分类为三类：
（1）功能需求：更多体现各级直接目标要求,系统具体要作什么. 有哪些功能点.
（2）质量需求：运行期质量 + 设计质量+用户质量+系统质量.
（3）约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素.

ADMEMS矩阵，可做为需求梳理和需求评审的工具:

 

3. 需求优先排序

架构设计的本质目的是为了解决业务，架构设计也并非面面俱到，而是识别问题有针对性的解决, 因此要先了解系统最须要解决的是什么。

例如系统的复杂度来源于业务逻辑复杂，功能耦合度严重，架构师设计TPS达到50000/s的高性能架构没有意义。

出现问题主要为了知足“高可用”“高性能”“可扩展”三个方面，就算老板拍脑壳要求同时知足三高,也要分优先级。

好比线上运行的系统可能存在的问题:

运行效率低下，升级复杂，容易出错。

开发效率低下。

小问题不断，很差定位。

解决方法：

列出主要的复杂度问题

根据业务、技术、团队等状况进行排序

优先解决最主要的复杂度问题.

4. 需求分析总参考图

 

2、架构愿景分析

1. 架构设计流程

 

2. 愿景和目标区别

有时候咱们常常把愿景和目标混为一谈,咱们首先须要区别愿景和目标:
（1）愿景笼统,目标具体，。好比：架构设计作作到高可用，高性能，高可扩展，这些是笼统的概念，没有具体的指标要求。
（2）目标是即将实现，可以经过努力实现的规划，愿景是一幅前景，可以指引咱们前进的理想。
（3） 愿景有助于肯定发展目标，发展目标为实现愿景服务。
（4）架构愿景：是一种团队心里的愿望，是脑筋的一幅图画，是一种驱动力，愿意实践、追求，来达到某一个境界，能追求到某一种成就。是团队成员但愿架构往哪一个方向发展，包括具体目标、设计原则、质量要求。
（5）架构目标：架构达成某些具体的指标，好比可用性达到99.99%等。
（6）所以我这里认为架构的愿景分析是包含目标.

3. 架构愿景的层次

架构的愿景是相对于一个范围来讲的，在一个特定的软件功能范围以内，谈架构愿景才有实际的意义，例如针对软件的全局或某个子系统/模块。在这个特定的范围中，订立了架构愿景以后，这个范围内的全部设计原则将不能违背架构愿景。这是很是重要的，是架构愿景的最大的用处。有了这样的保证，咱们就能够保证设计的一致性和有效性。任何一项设计的加入，都可以融入到原先的架构中，使得软件更加的完善，而不是更加的危险。

咱们根据架构适用范围的不一样，把架构愿景分为几个类别讨论：

 

3.1 软件系统全局(架构模式)
软件全局的架构是咱们所最关心的，所以也会花费最多的笔墨。
软件全局中的架构愿景通常很难具体化到代码级别，其实你会发现，就算是具体化到了代码级别，也会由于实际中存在的问题，致使代码没有太多的价值。所以，为软件全局设置的架构愿景能够以原则、或是架构模式的方式体现，并用天然语言或伪代码描述。例如，能够为一个系统规定三层架构做为其愿景，并指出三层的分类原则和具体目标。注意，咱们须要指出分类原则，不然规定三层架构并无太大的意义，由于三层架构随着实现平台的不一样、开发人员的不一样而有很大的差别，若是不可以规定一个可操做的规范，那么愿景是没有意义的。

3.2 子系统/模块级、或是子问题级的架构愿景
这时候的架构愿景已是比较明确的了，由于已经存在明确的问题域。例如界面的设计、领域模型的设计、持久层的设计等。这里的愿景制定本质上和全局的愿景制定差很少，具体的例子咱们也再也不举了。可是要注意一点，你不可以和全局愿景所违背。在操做上，全局愿景是设计团队共同制定出来的，而子/系统模块级的架构愿景就能够分给设计子团队来负责，而其审核则仍是要设计团队的共同参与。这有两个好处，一是确保各个子模块（子问题）间不至于相互冲突或出现空白地带，二是每一个子设计团队能够从别人那里吸收设计经验。

在设计时，一样咱们能够参考其它的资料，例如相关的模式、或规范（界面设计指南）。在一个有开发经验的团队，通常都会有开发技术的积累，这些也是可供参考的重要资料。

咱们在这个层次的愿景中主要谈一谈子模块（子问题）间的耦合问题。通常来讲，各个子模块间的耦合程度相对较小，例如一个MIS系统中，采购和销售模块的耦合度就比较小，而子问题间的耦合程度就比较大，例如权限设计、财务，这些功能将会被每一个模块使用。那么，咱们就须要为子模块（子问题）制定出合同接口（Contact Interface）。合同的意思就是说这个接口是正式的，不可以随意的修改，由于这个结构将会被其它的设计团队使用，若是修改，将会对其它的团队产生没法预计的影响。合同接口的制定、修改都须要设计团队的经过。此外，系统中的一些全局性的子问题最好是提到全局愿景中考虑，例如在源自需求模式中提到的信贷账务的例子中，咱们就把一个利息计算方式的子问题提到了全局愿景中。

3.3 代码级的愿景 (代码设计模式)
严格的说这一层次的愿景已经不是真正的愿景，而是具体设计了。可是咱们为了保证对架构设计理解的完整性，仍是简单的讨论一下。这一个层次的愿景通常能够使用类图、接口来表示。但在类图中，你不须要标记出具体的属性、操做，你只须要规定出类的职责以及类之间的相互关系就能够了。该层次愿景的审核须要设计子团队的经过。

而设计细分到这个粒度上，执行愿景设计的开发人员可能就只有一两个左右。可是比较重要的工做在于问题如何分解和如何归并。分解主要是从两个维度来考虑，一个是问题大小维，一个是时间长短维。也就是说，你（设计子团队负责人）须要把问题按大小和解决时间的长短分解为更细的子问题，交给不一样的开发人员。而后再把开发人员提出的解决方法组合起来。

4. 架构目标

4.1 提出指望目标
指望目标也是来源于需求，主要指客户(多是老板)或其余利益相关人提出的项目（产品）愿景。愿景表达了客户的目标以及对系统的指望。从愿景中咱们能够得到许多架构分析所须要知道的知识，例如明确客户最指望达到的目标，以此能够肯定场景与风险的优先级；了解客户的不一样目标，能够由此识别系统客户的不一样角色，明确不一样的利益相关人的态度。
（1）业务响应能力:
下降系统耦合， 提高对变化的响应速度。
改善系统架构， 更好地支持业务扩展。
创建流程引擎， 更灵活地支持业务流程变化。

（2）系统质量:
合理地增长或减小系统间交互及补偿， 提高系统性能、 稳定性。

（3）开发效率:
合理划分系统， 经过系统职责的分离， 对开发组的职责进行合理分配， 同时创建更完整的公共平台、 基础框架、 基础类库， 提升开发效率。

（4）运维水平:
完善配置、 监控、 预警、 日志系统， 提高系统运维配置效率及排查问题的速度.

4.2 架构具体目标:衡量系统好坏的标准
具体目标指标以下:
（1）正确性:系统首先须要正确，运行稳定
（2）可用性: 系统必须很是可靠，通常业界更倾向用 N 个9 来量化可用性， 最常说的就是相似 “4个9(也就是99.99%)” 的可用性。
（3）开发效率: 下降开发成本和下降公司在快速巨变的行业里面的时间和机会成本。互联网目前是一个快鱼吃慢鱼的时代，已经不是大鱼吃小鱼了。由于小鱼在一晚上之间就长大了，把大鱼吃掉了。
（4）伸缩性: 用户激增的时候，系统能够伸缩来支持用户的增加或流量高峰。
（5）安全性:安全也是一个商业公司的命脉，攻击、泄密、破解，前一段闹的沸沸扬扬的各类用户信息泄露，足以说明安全的重要性。
（6）扩展性:在增长新模块或者新的技术时，能比较容易的扩展。
（7）高性能:性能其实也是用户体验的一部分，尤为是用户量不断增多，性能是节省成本的重要手段。
（8）可维

 

4.3 肯定架构质量要求

 

3、架构设计原则

如何设计出一个好的架构，不像数据公式或者定律，很难一律而就。不少时候是设计者（架构师）的各类设想，各类权衡折中而符合系统需求的智慧输出。但咱们掌握前人总结的经验，让咱们站在巨人的肩膀上高山远瞩。一些好的架构设计原则能够确保设计决策在必定程度上可以知足需求。

1. 造成架构原则的过程

造成架构原则的过程：

 

架构原则要SMART

 

2. 常见的架构设计原则

2.1 N+1设计
开发的系统在发生故障时，至少有一个冗余的实例
普遍地应用在从数据中心设计到应用服务的部署：
在发生故障时，系统至少要有一个冗余的实例。
必须确保一个为本身，一个为客户、 一个为失败

2.2 回滚设计
确保系统能够向后兼容
若是好久才能修复服务，那么就要在必定的时间范围内完成回滚。
灾难性的事故，例如损坏客户数据，每每在部署后好几天才出现。
系统最好按照预先的设计，经过发布或回滚解决问题。

2.3 禁用设计
能够关闭任何发布功能
当设计系统，特别是与其余系统或服务通信的高风险系统时，要确保这些系统可以经过开关来禁用。这将为修复服务提供额外的时间，同时确保系统不由于错误引发诡异需求而宕机。

2.4 监控设计
在设计阶段就要考虑监控，而不是在部署完成后，经过监控发现系统的可用性问题。
（1）经过监控使系统自我诊断、自我修复成为可能。
（2）经过监控肯定系统可预留空间的使用状况。
（3）经过监控掌握系统之间的交互关系，发现瓶颈
若是监控作的好，不只能发现服务的死活，检查日志文件，还能收集系统相关的数据，评估终端用户的响应时间。若是系统和应用在设计和构建时就考虑好监控，那么即便不能自我修复，也至少能够自我诊断。

2.5 多活数据中心设计
数据是否所有集中在一个数据中心？
读写是否分离？
是否全部的客户信息都共享同一个数据结构？
服务调用是否容许延时的存在

2.6 采用成熟的技术
（1）工程师倾向于学习和实施性感时髦的新技术。由于新技术能够下降成本、减小产品上市时间、提升性能。不幸的是，新技术也每每有较高的故障率。若是把新技术应用在架构的关键部分，可能会对可用性产生显著的影响。
（2）最好争取在多数人采用该技术的时候进入，先把新技术用在对可用性要求不高的功能上，一旦证实它能够可靠地处理平常的交易，再将此技术移植到关键任务领域中去。

2.7 故障隔离
避免单一业务占用所有资源。避免业务之间的相互影响 2. 机房隔离避免单点故障。
不共享原则：理想状况是负载均衡、网络前端、应用服务器、数据库，毫不共享任何服务、硬件和软件。
不跨区原则： 不一样隔离区之间无通信，全部服务调用必须发生在同一个故障隔离区。

2.8 水平扩展
什么是水平可扩展？平台的水平扩展是指随着业务的发展，当须要扩大平台的服务能力时，没必要重构软件系统，经过增长新的设备来知足业务增加的须要。

 

X轴扩展：服务器拆分。平台的服务能力能够在不改变服务的状况下，经过添加硬件设备来完成扩容。
Y轴扩展：数据库拆分。平台的服务能力经过不断地分解和部署服务来完成扩容。
Z轴扩展：功能拆分。平台的服务能力能够按照客户不断分解和部署来机器 完成容量的扩展。（好比按用户uid来分表分库等）

 

2.9 非核心则购买
工程师每每有本身研发全部系统的冲动。
系统研发要投入资源，系统维护更要长期投入。
影响核心产品到市场的速度。
若是能够造成差别化的竞争优点，那么本身作，不然外购。

2.10 使用商品化硬件
在大多数状况下，便宜的是最好的。
标准、低成本、可互换、易于商品化是商品化硬件的特征。若是架构设计得好，就能够经过购买最便宜的服务器轻松地实现水平扩展，前提是全部商品化硬件的总成本要低太高端硬件的总成本。

2.11 快速迭代
小构建：小构建的成本较低，能够确保投资能够产生价值。
小发布：发布的失败率与变动数量相关，小发布失败率较低。
快试错：可依市场反馈，快速迭代，加快TTM，优化用户体验

2.12 异步设计
同步系统中个别子系统出现故障会对整个系统带来影响。
同步系统中性能最慢的子系统成为整个系统性能的瓶颈。
同步系统中扩展性最差的子系统是整个系统扩展的瓶颈。

2.13 无状态设计
无状态的系统更利于扩展，更利于作负载均衡。
状态是系统的吞吐量、易用性、可用性、性能和可扩展性的大敌，要尽最大可能避免。

2.14 前瞻性设计
Now ：目前正使用系统的架构、设计、能力、性能和扩展性。
Now+1: 下一代预研系统的架构、设计、能力、性能和扩展性。
Now+2: 下一代规划系统的架构、设计、能力、性能和扩展性

2.15 自动化
设计和构建自动化的过程。若是机器能够作，就不要依赖于人. 人常犯错误，更使人沮丧的是，他们每每会以不一样的方式屡次犯一样的错误。

3. 架构设计的关键原则

3.1 一个好的设计拥有如下几点
（1）解决现有需求和问题
（2）把控现实的进度和风险
（3）预测和规划将来，不要过分的设计，从迭代中演进和完善。
在开始设计以前，思考一下关键的原则，将会帮助你建立一个最小花费、高可用性和扩展性的架构。

3.2 分离关注点
将应用划分为在功能上尽量不重复的功能点。主要的参考因素就是最小化交互，高内聚、低耦合。可是，错误的分离功能边界，可能会致使功能之间的高耦合性和复杂性

3.3 职责单一
每个组件或者是模块应该只有一个职责或者是功能，功能要内聚。

3.4 最小知识原则
一个组件或者是对象不该该知道其余组件或者对象的内部实现细节。

3.5 不重复原则
你只须要在一个地方描述目的。例如，特殊的功能只能在一个组件中实现，在其余的组件中不该该有副本。

3.6 最小化预先设计
只设计必须的内容。在一些状况，你可能须要预先设计一些内容。另一些状况，尤为对于敏捷开发，你能够避免设计过分。若是你的应用需求是不清晰的，最好不要作大量的预先设计。

3.7 低耦合、高内聚
防止变异（使用接口和适配器防止变异）、关注分离。

3.8 关注分离
横向分层、纵向分区
(1) 将有关事务模块化，封装到单独的构件（例如子系统）中，而且调用其服务；
(2) 使用装饰者，将所关注的事物（例如安全）置入Decrator对象中，Decorator对象包裹内部类并提取其服务，装饰者在EJB技术中被称为容器，EJB容器围绕内部对象的业务逻辑，在外部的装饰者中增添安全检查；
(3) 使用后便以和面向方面的技术（Aspect-oriented），好比AspectJ以对开发者透明的方式支持在编译以后将横切面关注织入代码。

3.9 关注点分离之道
好的架构设计必须把变化点错路有致地封装到软件系统的不一样部分，为此，必须进行关注点分离。关注点相互分离，也就是说系统中的一部分发生变化，不会影响其余部分。即便须要改变，也可以清晰地识别出哪些部分须要改变。若是须要扩展架构，影响将会最小化，已经能够工做的每一个部分均可以继续工做。

首先，能够经过职责划分来分离关注点。面向对象设计的关键所在，就是职责的识别和分配。每一个功能的完成，都是经过一系列职责组成的协做链条完成的，当不一样职责被合理分离以后，为了实现新的功能只需构建新的协做链条，而需求变动页每每只会影响到少数职责的定义和实现。

其次，能够利用软件系统各部分的通用性的不一样进行关注点分离。不一样的通用程度意味着变化的可能性不一样，将通用性不一样的部分分离有利于通用部分的重用，页便于对专用部分进行修改。

另外，还能够先考虑大粒度的子系统，而暂时忽略子系统是如何经过更小粒度的模块和类组成的。在实际中，软件架构师经常将系统划分为一组子系统，并为子系统定义明确的借口，其中的细节将随其后的开发工做慢慢展开。

根据职责分离关注点、根据通用性分离关注点、根据不一样粒度级别分离关注点是三种不一样维度的思惟方式。

3.10 非侵入性原则
那么什么是架构的侵入性呢？所谓侵入性就是指的这个架构设计出来的部件对系统的影响范围，好比框架的侵入性就很高，由于在一个工程中引入一个框架，你的整个设计都必须围绕这个框架来进行，一旦使用了，框架的可替代性几乎为0，这样子就是搞侵入性。组件的侵入性就比较低,好比ibaties，他能够在任何java框架下使用，甚至能够和其余ORM组件共存，你仅仅须要引入，配置，而后就能够使用了，你也能够用其余的ORM替换他，因此......这个体验应该是很愉快的。
因此话说回来讲到若是咱们在设计一个通用架构的时候就应该注意到这个一个很是重要的地方，除非咱们只是本身拿来用用，不然咱们不该该假设咱们的设计的用户已经具有怎么怎么样的环境或者是须要作什么特殊的设计才可以使用。
这里打个比方，假如说咱们在设计一个通用权限管理什么什么的时候咱们就要想好，这是一个组件，仍是框架，仍是一个现成系统（复用经过改改代码实现，其实我的以为这种设计很低级，虽然有的这样子的东西功能确实丰富）。肯定了目标以后咱们才好开始下一步，好比肯定是一个框架的话可能发挥要自由一些，由于不须要高度的内聚，不过可能由于框架要设计的方方面面太多了，因此总是以为我的的力量不足以搞这种东西出来。若是是组件的话就须要高度的内聚来实现非侵入式，好比引入DLL的时候还须要让全部页面继承自某个基类页就不算是一个good idear。

4、必备设计-API网关

1. 网关概念介绍

API Gateway（API GW / API 网关），顾名思义，是企业 IT 在系统边界上提供给外部访问内部接口服务的统一入口。在微服务概念的流行以前，API网关的实体就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换、访问统计等问题的。

百度百科：API网关是一个服务器，是系统的惟一入口。从面向对象设计的角度看，它与外观模式相似。API网关封装了系统内部架构，为每一个客户端提供一个定制的API。它可能还具备其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。

API网关方式的核心要点是，全部的客户端和消费端都经过统一的网关接入微服务，在网关层处理全部的非业务功能。一般，网关也是提供REST/HTTP的访问API。服务端经过API-GW注册和管理服务。

2. API网关分析设计

2.1 宏观分析要素
安全性问题
企业在把服务暴露给外部使用时，首先要确保服务使用的安全，防止外部的恶意访问对公司业务的影响，特别是涉及交易方面的服务，更是要全面考虑安全性。为确保安全，须要考虑在通信链路的创建、通信数据的加密、数据的完整性、不可抵赖性等方面。

性能问题
做为企业API的入口，全部的请求都会通过API网关进行转发，可想而知，对API网关的访问压力是巨大的，有的网站甚至达到每分钟上千万的访问量。特别是在一些互联网企业，海量的移动终端每时每刻都须要与后端的服务进行交互，若是不能保证网关的高性能，企业在网关层须要投入大量的设备和成本。曾在一家互联网公司发生过，因为网关性能问题，网关的机器数量，须要与后台服务器的数量保持同步增加。这种状况显然是企业服务忍受的。

高可用问题
API网关做为逻辑上的单点，一旦发生问题，将形成企业服务的不可用，对企业来讲可能形成的致命的影响。计算短期的不可用，也会给企业带来直接的经济损失。因此，如何保证API网关的7*24小时的稳定运行，网关的自动伸缩、API的热更新等问题，都是企业级的网关须要考虑的。

扩展性问题
前面说到，企业网关提供了一个脚手架，一些非功能性的问题，例如日志、安全、负载均衡策略、鉴权等。这些插件会随着企业业务规模等的变化进行不断的强化与调整。这就须要网关层提供这样一种机制，使得能够灵活地进行这些调整和变化，而不用频繁对网关层进行改动，确保网关层的稳定性。

API高效运维的问题
API在上线、发布过程当中，都须要涉及到网关层的配合，例如，须要网关层知道API发布的地址，API的接口形式、报文格式，也须要网关层对后台API进行封装。在API调整后，须要做出相应的修改。因此，API网关设计时，须要明确网关层与服务层的职责切分与协做模式，使得API的管理、发布更加高效。

API全生命周期的管理
API服务的全生命周期，包括服务的开发、测试、上线发布；服务使用的申请、开通；服务分类分级别的管理、服务使用状况的监控、计费等等。
一个企业可能会暴露成百上千个API，平常也会常常进行API的发布、升级、改造、下架等操做。对不一样的服务，不一样的访问者，须要提供不一样的服务访问策略。有的商业API公司，还须要对API的使用进行付费。因此，与API网关配套的，须要一套完善的自助系统，提供给服务的提供者、管理者、使用者，来对服务的发布、使用、和运营。

2.2 具体状况分析
功能需求
一、API 生命周期管理功能：
覆盖 API 的定义、测试、发布的整个生命周期管理，便捷的平常管理、版本管理，支持热升级和快速回滚

二、开发和使用支持功能：
提供页面调试工具，自动生成 API 文档和 SDK，大大下降人力成本。

三、安全防御功能：
API 请求到达网关须要通过严格的身份认证、权限认证，才能到达后端服务。支持算法签名，支持 SSL 加密。

四、流量控制功能：
可控制单位时间内 API 容许被调用次数。用来保护企业的后端服务，实现业务分级和用户分级。 支持对 API 流控，您能够根据 API 的重要程度来配置不一样流控，从而保障重要业务的稳定运行； 支持用户、应用和例外流控，您能够根据用户的重要性来配置不一样流控，从而能够保证大用户的权益； 流控粒度：分钟、小时、天。

五、请求管理功能：
可根据配置进行参数类型、参数值（范围、枚举、正则、Json Schema）的校验，减小后端对非法请求、无效请求的资源消耗和处理成本。能够在 API 网关定义参数映射规则，网关经过映射规则将后端服务经过映射翻译成任何形式，以知足不一样用户的不一样需求，从而避免功能重复开发。

六、监控告警功能：
提供实时、可视化的 API 监控，包括：调用量、调用方式、响应时间、错误率，让您可以清楚的了解 API 的运行情况和用户的行为习惯。
支持自定义报警规则，来针对异常状况进行报警，下降故障处理时间。
提供可订阅的数据分析报表和智能分析。

高性能设计
传统的基于线程的并发模型（Thread-based concurrency），为每个请求分配一个线程或进程。这种模型编程简单，能够将处理一个完整请求的代码编写在一个代码路径中。这种模型的弊端是，随着线程(进程)数的上升，操做系统在这些线程(进程)之间的频繁切换，将急剧下降系统的性能。

 

高可用设计
一、无状态设计原则。
网关层为保证高能够，易于伸缩，快速启动，须要设计成无状态的。用户的状态数据咱们一般使用session对象来封装，网关层要设计成无状态的，也就是说，不能由网关来负责session的维护。那由谁来维护session相关的信息呢？咱们是采用cookie+session服务器的方式;
a) 用户在登陆页完成登陆操做后，服务器会生成一个登陆session信息，保存起来，设置个失效时间，并设置到用户的cookie里
b) 用户后续的每次请求里会带着这个cookie信息，服务端会对这个cookie信息进行校验，经过了就认为是合法用户，执行请求操做

二、优雅下线原则
当须要撤掉一台网关服务的时候，不是直接结束网关进程，而是先关闭监听套接字，可是继续为当前链接的客户提供服务，全部客户端的服务完成后，在把进程关闭。

三、Slow start特性
当网关监听到有一台新的服务注册上来时，考虑到有些服务启动后，刚开始会有许多初始化的工做，此时服务对请求的响应速度是比较慢的。若是一开始就给这台服务分配太多的压力，有可能致使服务瞬间被压垮。为了不这种状况，网关层须要考虑支持Slow Start特性。即，通过一段时间，逐渐把压力增长到预设的值。

四、扩展性设计
咱们知道，网关对请求的处理，能够分为三个阶段：接受请求、路由并转发请求、接受服务的返回数据并返回给请求者，除此以外，还有一种状况是处理错误。因此咱们也能够在这四个地方添加扩展点。
（1）接受到请求后
（2）定位到一个服务，并准备转发以前
（3）接受到服务的返回数据，返回给客户端以前
（4）当服务调用失败后
拦截器的处理顺序，能够分为两大类：一类为网关平台自带的拦截器，例如安全校验、日志记录等；一类为网关层逻辑开发的，例如格式转换等。通常来讲，网关先执行网关平台自带的拦截器，再执行为了业务逻辑编写的拦截器。固然，网关也须要提供一种机制，能够较容易地调整拦截器的执行顺序。最简单的一种方法，就是给每一个拦截器定义一个优先级，网关按优先级顺序依次调用各拦截器。
对网关层来讲，它接收和处理的数据都是Request对象，网关层在接收到请求后，把请求封装为Request对象，为了让后续的filter可以得到这个对象，能够考虑把Request对象保存在线程变量中。
有些拦截器，例如一些调试日志的拦截器，一般状况下都是关闭的，只有在出现问题的时候才须要打开。为了保证网关的高可用，网关层必须具有在线启用或关闭拦截器的能力。通常，网关须要提供restful接口方式，来关闭和启用一个拦截器。相似这样的命令：PUT /apigateway/v1/filters/filterName?enable=value

五、API管理与动态发布设计
对服务管理来讲，分为前端服务管理与后端服务管理。前端服务指的是网关层暴露给客户端使用的服务API，后端服务指的是服务层提供的业务服务API。一个服务暴露给客户端使用，除了网关层和服务层提供服务的代码外，还须要配置前端服务与后端服务的映射关系。
网关层API调用服务层API，有多种方式。例如，能够由按照服务层API的服务契约，生成一段客户端代码，发布给网关层使用。这种方式的弊端是，网关层代码依赖于服务层代码，服务层频繁修改和调整接口时，致使网关层的代码很难维护。
能够经过配置先后端服务映射的方式，解耦网关层对服务层的依赖。当服务层的API（例如服务名、参数名等）发生变化时，只需调整映射关系，无需对网关层的代码进行调整。网关层按照映射，自动装配服务层API所须要的数据格式。这样，网关层团队与服务层团队能够相互不受干扰地开发各自的服务。

3. 优缺点介绍

3.1 优势
（1）解耦做用：它封装了应用的内部结构，客户端直接和网关通讯，而没必要调用特定的服务。
（2）提供给每种客户端特定优化的API。
（3）减小请求环路、简化客户端逻辑。好比说，API Gateway使得客户端用一次请求就能够从多个service处获取数据。

3.2 缺点
（1）必须被开发、部署和管理成一个高度可用的组件，也有成为开发瓶颈的危险。
（2）为了暴露出每一个微服务的，开发者必须更新API网关。
（3）Partner OpenAPI：
转发路由做用：对外提供的接口服务，通常直接把请求转发到合适的service，可是此时的API GW须要增长配额、限流、令牌等一系列安全管控功能。对外提供隔离做用：请求路由，安全认证，负载均衡，限流、监控、权限控制等等。

4. 业界经常使用的API网关方案

一般状况下， API 网关要作不少工做，它做为一个系统的后端总入口，承载着全部服务的组合路由转换等工做，除此以外，咱们通常也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来作，那么能够试想在高并发的状况下，这里可能会出现一个性能瓶颈。
另外，若是没有开源项目的支撑前提下，本身来作这样一套东西，是很是大的一个工做量，并且还要作 API 网关自己的高可用等，若是一旦作很差，有可能最早挂掉的不是你的其余服务，而就是这个API网关。
4.1 基于OpenResty 的 Nginx
性能和高可用性
Nginx性能极高，Nginx先天的事件驱动型设计、全异步的网络I/O处理机制、极少的进程间切换以及许多优化设计，都使得Nginx天生善于处理高并发压力下的互联网请求。Nginx的稳定性也在各大网站获得验证。官方提供的经常使用模块都很是稳定，每一个worker进程相对独立，master进程在1个worker进程出错时能够快速“拉起”新的worker子进程提供服务。支持热部署，能够不停机更新配置文件、更新日志文件、更新服务器程序版本。

扩展性上
Nginx的设计极具扩展性，它彻底是由多个不一样功能、不一样层次、不一样类型且耦合度极低的模块组成。所以，当对某一个模块修复Bug或进行升级时，能够专一于模块自身，无须在乎其余

易用性上
Nginx使用最自由的BSD许可协议，容许用户在本身的项目中直接使用或修改Nginx源码，有大量的插件能够利用。可是，Nginx模块须要用C开发，并且必须符合一系列复杂的规则。虽然经过第三方模块，能够支持Nginx与Perl、Lua等脚本语言集成工做，但对使用者的要求仍是很高。

4.2 Spring Cloud Zuul

 

基本功能
验证与安全保障: 识别面向各种资源的验证要求并拒绝那些与要求不符的请求。
审查与监控: 在边缘位置追踪有意义数据及统计结果，从而为咱们带来准确的生产状态结论。
动态路由: 以动态方式根据须要将请求路由至不一样后端集群处。
压力测试: 逐渐增长指向集群的负载流量，从而计算性能水平。
负载分配: 为每一种负载类型分配对应容量，并弃用超出限定值的请求。
静态响应处理: 在边缘位置直接创建部分响应，从而避免其流入内部集群。
Netflix公司还利用Zuul的功能经过金丝雀版本实现精确路由与压力测试。
虽然提供的功能还算丰富，但都比较弱，很难知足高要求的场景。

性能和高可用性
Zuul处理每一个请求的方式是针对每一个请求是用一个线程来处理。一般状况下，为了提升性能，全部请求会被放处处理队列中，从线程池中选取空闲线程来处理该请求。2016年末，Netflix将它们的网关服务Zuul进行了升级，全新的Zuul 2将HTTP请求的处理方式从同步变成了异步，以提高其处理性能。除了Netflix公司，目前Zuul在企业中用的还比较少，性能和稳定性方面还有待进一步观察。

扩展性上
从Zuul的架构图上能够看出，Zuul更像是一个过滤器框架，其自身的路由、日志、反向代理、ddos预防等功能都是经过过滤器实现的。提供了PRE、ROUTING、POST和ERROR四个扩展点，能够很容易的添加自定义的过滤器。

易用性上
Zuul的搭建很是简便，使用和配置也很简单。Zuul的开源社区比较活跃，一直在更新状态，但版本不算太稳定，在使用的过程当中，还有一些坑要踩。例如重定向问题、异常处理问题，尚未解决的很好，须要本身重写一些filter。

4.3 Mashape Kong

 

Kong的一个很是诱人的地方就是提供了大量的插件来扩展应用，经过设置不一样的插件能够为服务提供各类加强的功能。Kong默认插件插件包括：

身份认证
Kong提供了Basic Authentication、Key authentication、OAuth2.0 authentication、HMAC authentication、JWT、LDAP authentication认证明现。

安全
ACL（访问控制）、CORS（跨域资源共享）、动态SSL、IP限制、爬虫检测实现。

流量控制
请求限流（基于请求计数限流）、上游响应限流（根据upstream响应计数限流）、请求大小限制。限流支持本地、Redis和集群限流模式。

分析监控
Galileo（记录请求和响应数据，实现API分析）、Datadog（记录API Metric如请求次数、请求大小、响应状态和延迟，可视化API Metric）、Runscope（记录请求和响应数据，实现API性能测试和监控）。

请求转换、响应转换
Kong自己也是基于Nginx的，因此在性能和稳定性上都没有问题。Kong做为一款商业软件，在Nginx上作了很扩展工做，并且还有不少付费的商业插件。Kong自己也有付费的企业版，其中包括技术支持、使用培训服务以及 API 分析插件。
从对上面三种方案的比较中能够看到，Spring Cloud Zuul很是适合创业初期的团队，快速搭建一个“基本可用”的API网关。Nginx适合有较强研发团队，自主开发企业本身的API网关。Kong适合于没有自身研发团队，但须要拥有企业级API网关能力的公司。

5、参考文章

1. https://mp.weixin.qq.com/s/YOxX65s-eaXTWW8eSwvaZQ
2. https://mp.weixin.qq.com/s/LRQaFbwk1UOuOQPYwu2Ovw
3. https://mp.weixin.qq.com/s/nbtniSjr06rfboiYaW0IsQ
4. https://mp.weixin.qq.com/s/SUt-mFYSkNHx6QA2UkNW1w