架构师学习周记（一）

缘起

  日子一天天过去，离软考架构师只剩下58天，为了充分利用复习时间，我决定把007的作业和架构师的复习结合在一起，每周写一篇文章来对每周复习的重点内容进行复盘。-----2018-9-13

---

一、SOA的关键技术

1、UUDI
UUDI（Universal Description Discovery and Integration，统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。

在UDDI技术规范中，主要包含一下三个部分的内容：
（1）数据模型。用于描述业务组织和服务的XML Schema。
（2）API。一组用于查找和发布UDDI数据的方法，基于SOAP。
（3）注册服务。是SOA中的一种基础设施，对应着服务注册中心的角色。

2、WSDL
WSDL（Web Service Description Language，Web 服务描述语言）是对服务进行描述的语言，它有一套基于XML的语法定义。WSDL描述的重点是服务，它包括服务实现定义和服务接口定义。

3、SOAP
SOAP（Simple Object Access Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call，RPC）。

SOAP主要包括以下四部分：
（1）封装。用来表示消息中包含什么内容，谁来处理这些内容，以及是否必需。
（2）编码规则。定义了一种序列化机制，用于交换系统所定义的数据类型的实例。
（3）RPC表示。定义了一个用来表示远程过程调用和应答的协议。
（4）绑定。定义了一个使用底层传输协议来完成在节点之间交换SOAP封装的约定。

SOAP消息基本上是从发送端到接收端的单项传输，但它们常常结合起来执行类似于请求/应答的模式。

SOAP消息包括以下三部分：
（1）封装（信封）。元素名是Envelope，封装是顶层元素，必须出现。
（2）SOAP头。元素名是Header，可有可无。
（3）SOAP体。Body，包含消息的最终接收者想要的信息的容器，必须出现。

样例
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
<soap:Body xmlns:m="http://www.example.org/stock">
</soap:Body>
</soap:Envelope>

4、REST
REST（Representational State Transer，表述性状态转移）是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性，从根本上来说只支持几种操作（POST、GET、PUT、DELETE）。

REST提出了如下设计概念和准则：
（1）网络上所有事物都可以被抽象成资源。
（2）每个资源都对应一个唯一的资源标识。
（3）通过通用的连接件接口对资源进行操作。
（4）对资源的各种操作不会改变资源的标识。
（5）所有的操作都是无状态的。

二、SOA的实现方法

从逻辑上和高层抽象来看，目前，实现SOA的方法比较多，其中主流方式有Web Service、企业服务总线和服务注册表。

1、Web Service

Web Service 模型

Web Service 模型中的操作包括发布、查找和绑定，发布和查找顾名思义，无需太多解释，关于绑定，可能很多研发的同事并不太熟悉。在绑定操作中，服务请求者使用服务描述中的绑定细节来定位、联系并调用服务，从而在运行时与服务进行交互。绑定可以分为动态绑定和静态绑定。

• 动态绑定：简而言之，就是通过服务注册中心查找服务描述，并动态地与服务交互（并不提前知道服务的存在）；
• 静态绑定:就是服务提供方和服务调用方提前约定好，通过本地文件或其他方式直接与服务进行绑定（小规模系统对接用的比较多的方式）。

在采用Web Service 作为SOA的实现技术时，应用系统大致可以分为六个层次，分别是：

• 底层传输层 ==》消息的传输机制（HTTP、JMS、SMTP）
• 服务通信协议层 ==》服务之间进行消息传递所需的技术标准（SOAP和REST协议）
• 服务描述层 ==》统一方式来描述服务的接口和消息交换方式（WSDL）
• 服务层
• 业务流程层
• 服务注册层

2、服务注册表
主要在SOA设计时使用，任何帮助服务注册、发现和查找服务合约、元数据和策略的信息库、数据库、目录或者其他节点，都可以认为是一个服务注册表。

3、ESB企业服务总线
ESB是由中间件技术实现并支持SOAde一组基础架构，是传统中间件技术与XML、Web Service等技术结合的产物，是整个企业集成架构下的面向服务的企业应用集成机制。

具体来说，ESB具有一下功能：
（1）支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性。
（2）几乎不改代码通过配置，就可以使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准。
（3）充当缓冲器的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑想分离。
（4）提供诸如服务代理和协议转换等功能。
（5）提供可配置的消息转换翻译机制和基于消息内容的消息路由服务。
（6）提供安全和拥有者机制，保证消息和服务使用的认证、授权和完整性。

ESB的优势：
（1）扩展的、基于标准的连接。
（2）灵活的、服务导向的应用组合。
（3）提高复用率，降低成本。
（4）减少市场反应时间，提高生产率。（构件和服务的复用）

三、微服务

微服务，顾名思义，就是很小的服务，所以它属于面向服务架构的一种，就像活字印刷术一样，每个服务就是一个组件，通过编排组合的方式来使用，从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达到提高交付质量、速断交付周期的效果。

1、核心特点
微服务的核心特点就是小，且专注于做一件事，轻量级的通信机制、松耦合、每个服务都是独立部署的。

2、优势

• （1）技术异构性：意思就是微服务的每个服务都是一个独立的个体，所以它可以做新技术的试验场，比如我们需要在现有的架构引入一种新的DB或者使用一种新的编程语言，如果是传统架构的话，这个影响就非同寻常，需要做大量的测试，但是如果在微服务架构中，你可以选择的某一个微服务或者新增加的微服务中进行试验，对整体系统的影响就可以降低到最小。同时，由于不同的微服务之间可能有不同的质量属性要求，这样的情况下就可以为不同的微服务选择使用适合自身的技术。

• （2）弹性：可以进行内置可用性解决方案和功能降级方案。

• （3）扩展：可以针对单个服务进行扩展，不必担心单个服务的扩展对整个系统造成影响。

• （4）简化部署：不需因代码变动重新部署整个系统，只需要重新部署特定的服务。

• （5）与组织结构相匹配

• （6）可组合性

• （7）对可替代性的优化

3、面临的挑战

• （1）分布式系统的复杂度
  性能方面微服务是拆分成多个服务进行部署，服务间的通信都是通过网络，此时的性能会受影响。同时可靠性也会受影响。数据一致性也要严格控制，成本比单块系统要高。
• （2）运维成本
  同样由于分开部署的原因，所以进行部署、集成、配置、监控或者日志收集等，成本比较高。
• （3）部署自动化
  用于微服务的服务节点比较多，所以部署的时候需要用到持续集成的自动化部署技术，如何有效地构建自动化部署流水线，降低部署成本、提高部署效率，是微服务架构下需要面临的一个挑战。
  -（4）DevOps与组织结构
  DevOps作为微服务架构中不可或缺的一部分，如何传递DevOps文化的价值，让团队理解DevOps文化的价值，并构建全功能团队，也是一个不小的挑战。
• （5）服务间依赖测试
  服务比较多，如何保证服务的功能正确性，以及服务间正常地进行交互。
• （6）服务间依赖管理
  如何进行服务间依赖的管理，清晰有效地展示服务间的依赖关系，成为了一个挑战。