微服务（Microservices）

在过去的 2016 年和 2017 年，微服务技术迅猛普及，和容器技术一起成为这两年中最吸引眼球的技术热点。而以 Spring Cloud 为代表的传统侵入式开发框架，占据着微服务市场的主流地位。

微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

形像一点来说，微服务架构就像搭积木，每个微服务都是一个零件，并使用这些零件组装出不同的形状。通俗来说，微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。

如果学科派一点，微服务架构就是把因相同原因而变化的功能聚合到一起，而把因不同原因而变化的功能分离开，并利用轻量化机制（通常为 HTTP RESTful API）实现通信。

微服务架构 ≈ 模块化开发 + 分布式计算。

需要注意的是**“微服务**”与“微服务架构”是有本质区别的。“微服务”强调的是服务的大小，它关注的是某一个点。而“微服务架构”则是一种架构思想，需要从整体上对软件系统进行通盘的考虑。

微服务架构示意图：

常见的微服务组件及概念：

服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址。
负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
服务网关：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
配置中心：将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
API 管理：以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
分布式事务：对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。

微服务架构的优点：

降低系统复杂度：每个服务都比较简单，只关注于一个业务功能。
松耦合：微服务架构方式是松耦合的，每个微服务可由不同团队独立开发，互不影响。
跨语言：只要符合服务 API 契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。
独立部署：微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得 CI／CD 成为可能。
Docker 容器：和 Docker 容器结合的更好。
DDD 领域驱动设计：和 DDD 的概念契合，结合开发会更好。

微服务架构的缺点：

微服务强调了服务大小，但实际上这并没有一个统一的标准：业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。有些开发者主张 10-100 行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。
微服务的分布式特点带来的复杂性：开发人员需要基于 RPC 或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。
分区的数据库体系和分布式事务：更新多个业务实体的业务交易相当普遍，不同服务可能拥有不同的数据库。CAP 原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。
测试挑战：传统的单体WEB应用只需测试单一的 REST API 即可，而对微服务进行测试，需要启动它依赖的所有其他服务。这种复杂性不可低估。
跨多个服务的更改：比如在传统单体应用中，若有 A、B、C 三个服务需要更改，A 依赖 B，B 依赖 C。我们只需更改相应的模块，然后一次性部署即可。但是在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新 C，然后更新 B，最后更新 A。
部署复杂：微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。因此，成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。
总的来说（问题和挑战）：API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用。
不过，现在很多微服务的框架（比如 Spring Cloud、Dubbo）已经很好的解决了上面的问题。

服务网格（Service Mesh）

2017 年底，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。

Service Mesh 又译作“服务网格”，作为服务间通信的基础设施层。

如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

Service Mesh 的来龙去脉：

1. 从最原始的主机之间直接使用网线相连
2. 网络层的出现
3. 集成到应用程序内部的控制流
4. 分解到应用程序外部的控制流
5. 应用程序的中集成服务发现和断路器
6. 出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，这时候还是集成在应用程序内部
7. 出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
8. 最后作为微服务的中间层 Service Mesh 出现

Service Mesh 有如下几个特点：

应用程序间通讯的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh 架构图：

目前流行的 Service Mesh 开源软件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（开源 Linkerd 的公司）又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit。

Service Mesh 开源项目简介：

Linkerd：第一代 Service Mesh，2016 年 1 月 15 日首发布，业界第一个 Service Mesh 项目，由 Buoyant 创业小公司开发（前 Twitter 工程师），2017 年 7 月 11 日，宣布和 Istio 集成，成为 Istio 的数据面板。
Envoy：第一代 Service Mesh，2016 年 9 月 13 日首发布，由 Matt Klein 个人开发（Lyft 工程师），之后默默发展，版本较稳定。
Istio：第二代 Service Mesh，2017 年 5 月 24 日首发布，由 Google、IBM 和 Lyft 联合开发，只支持 Kubernetes 平台，2017 年 11 月 30 日发布 0.3 版本，开始支持非 Kubernetes 平台，之后稳定的开发和发布。
Conduit：第二代 Service Mesh，2017 年 12 月 5 日首发布，由 Buoyant 公司开发（借鉴 Istio 整体架构，部分进行了优化），对抗 Istio 压力山大，也期待 Buoyant 公司的毅力。
nginMesh：2017 年 9 月首发布，由 Nginx 开发，定位是作为 Istio 的服务代理，也就是替代 Envoy，思路跟 Linkerd 之前和 Istio 集成很相似，极度低调，GitHub 上的 star 也只有不到 100。
Kong：比 nginMesh 更加低调，默默发展中。

关于微服务和服务网格的区别，我的一些理解：微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合。

目录

汽车服务架构(SOA)开发设计

1.什么是SOA

1.1 SOA优缺点

1.2 SOA 应用优势

1.3 服务的基本结构

1.4 SOA架构的核心要素

1.5 SOA服务架构开发趋势

1.6 SOA与E/E架构

1.6.1 域控制为核心的架构

1.6.2 区域控制为核心的SOA架构

1.7 以服务为核心的SOA开发思路

1.7.1 AP（Adaptive Platform）的开发

a. 定义服务内容

b. 定义服务接口

c. 配置服务关系

d. 通讯协议设计

2. SOA设计

2.1  SOA 设计原则

2.2  服务构件与传统构件

2.3  关键技术

2.3.1  UDDI 

2.3.2 WSDL 

2.3.3 SOAP

2.3.4 REST 

2.3.5 ESB

2.4 SOA实现

2.4.1  Web Service

2.4.2 服务注册表

2.4.3 企业服务总线

2.5 SOA实现基础

2.6 开发流程

2.7 开发工具链

2.8 SOA的应用实例

3. 汽车SOA开发

3.1面向服务架构的汽车软件及开发方法

3.1.1 如何分析和设计服务架构

3.1.2 如何建模和记录面向服务的架构

3.1.3 如何部署和实现面向服务的软件

3.1.4 SOA汽车软件创新平台

3.2 面向服务架构的汽车软件分析和设计

3.2.1 系统需求分析

3.2.2 系统功能分析

3.2.3 候选服务分析

3.2.4 系统架构设计

3.2.5 软件架构设计

3.3 面向服务架构（SOA）的汽车软件实现和部署

3.3.1 满足 SOA 架构的服务组件架构SCA

(Service-Component-Architecture)

3.3.2 服务组件架构SCA的配置描述

3.3.3 汽车SOA软件的实现方案

3.3.4 SOA服务组件实现和部署的具体步骤

3.4 核心模型设计

3.5 图表设计

3.6 服务设计

3.7 AP平台SOA相关技术规范概述

4. SOA流程开发在自动驾驶车企中布局

5. 企业管理开发流程与SOA软件架构开发之间的关系

6. SOA的两种不同开发模式原理

6.1业务驱动型开发

6.2平台驱动型开发

7. 基于AUTOSAR的SOA开发

7.1 基于AUTOSAR的SOA软件架构

7.2 基于SOA构建软件设计方法

7.3 系统架构-虚拟功能总线

7.4 SOA软件分层

7.4.1 应用软件

7.4.2 实时运行环境

7.4.3 基础软件

7.5 基于AUTOSAR的SOA服务

7.6 硬件抽象

7.7 基于AUTOSAR的SOA系统配置

8.总结

1.什么是SOA

SOA (服务导向架构，Service Oriented Architecture)  作为一种架构范式，展示了技术中立的最佳实践。其建立在标准之上，可在供应商的广泛支持下在全球范围内实现经济高效的实施。以在企业内部和跨企业创建新业务功能方面重用和重新组合服务，SOA很好的做到了“粗粒度”和“松散耦合”的特点，相较于当前分布式物理架构具有更大的灵活性。SOA 最佳实践创建包含业务流程的设计 —— 并增强将流程外包和扩展给业务合作伙伴的能力。此外，SOA也可以复用已有的系统和流程，与传统的基于孤岛的应用程序开发更具战术性的本质形成对比，可以保留和增强现有投资承建的架构、软件等实现的部分有用性。

1.1 SOA优缺点

优点：

1. 扩展方便：可针对单个服务提供资源扩展
2. 语言通用：接口通用，服务可以基于任何语言
3. 新人友好：单一模块服务理解透彻即可服务此模块，不必理会架构
4. 发版方便：可更新单一模块，不影响架构

缺点：

1. 问题排查不便：功能调用服务多，很难直接定位问题点
2. 沟通不便：模块独立，不确定其他模块状态
3. 性能问题：通信时间损耗
4. 关系混乱：服务越来越多，调用方越来越多的时候，就会比较混乱
5. 运维难度：随着服务的增多，系统架构会越发复杂，这就给运维层面带来了挑战
6. 数据一致性问题：单体项目因为数据都在同一个数据库里面，不需要过多的关注分布式事务等问题，SOA就需要关心了

1.2 SOA 应用优势

早期的车内嵌入式软件没有统一标准，基础软件和应用软件强耦合，不具可移植性；AUTOSAR Classic 的应用，对嵌入式基础软件的接口进行标准化，让应用开发者基于统一的基础软件接口进行应用开发。目前采用SOA软件服务架构的应用打通了车内的电子电气架构的壁垒，进一步对嵌入式应用软件的接口(即服务接口)进行了标准化，让APP开发者基于统一基础服务接口进行应用的迭代开发，隐藏了不同车型配置下应用软件的差异，真正做到了整车级软件接口的"标准"和"开放"。

平台架构升级更便于实现，通过服务设计的方式，能够有效降低架构升级带来的复杂度；同时，由于操作系统跨平台的难度大幅度降低，能够大幅提升用户体验，能够实现更为便捷的联网功能，实现不同平台间的各种APP共享等功能；

通过“服务Hub”区域控制器的引入，各种新功能能够灵活地与其他域功能，乃至互联网接口集成，而无需各个控制器各自进行信号到服务的转换； 

一些相对独立的域开发能够打破界限，找到新的上限，例如自动驾驶功能不再是电子电气架构“孤岛”，通过区域控制器进行服务互通，可以轻松实现高清地图的创建、更新及路线预测等功能，便于实现车辆信息的上传及云端指令的下达。

1.3 服务的基本结构

独立的服务结构如下图

服务模型的表示层从逻辑层分离出来，增加了服务对外的接口层。通过对服务接口的标准化描述，使得服务可以提供给在任何异构平台和任何用户接口使用。这允许并支持基于服务的系统成为松散耦合、面向构件和跨技术实现，服务请求者很可能根本不知道服务在哪里运行、是由哪种语言编写的，以及消息的传输路径，而是只需要提出服务请求，然后就会得到答案。

1.4 SOA架构的核心要素

要准确全面理解SOA，首先必须理解SOA的核心要素：

SOA的目标就是实现灵活可变的IT系统。要达到灵活性，通过三个途径来解决：标准化封装、复用、松耦合可编排。

互操作(标准化封装)、复用、松耦合等SOA技术的内在机制，也是中间件技术和产品的本质特征。

标准化封装（互操作性）

传统软件架构，因为封装的技术和平台依赖性，一直没有彻底解决互操作问题。互联网前所未有的开放性意味着各节点可能 采用不同的组件、平台技术，对技术细节进 行了私有化的约束，构件模型和架构没有统一标准，从而导致架构平台自身在组件描述、发布、发现、调用、互操作协议及数据传输等方面呈现出巨大的异构性。各种不良技术约束的结果是软件系统跨互 联网进行交互变得困难重重，最终导致了跨企业/部门的业务集成和重组难以灵活快速的进行。

在软件的互操作方面，传统中间件只是实现了访问互操作，即通过标准化的API实现了同类系统之间的调用互操作，而连接互 操作还是依赖于特定的访问协议，如JAVA使用RMI，CORBA使用IIOP等。而SOA通过标准的、支持Internet、与操作系统无 关的SOAP协议实现了连接互操作。而且，服务的封装是采用XML协议，具有自解析和自定义的特性，这样，基于SOA的中间 件还可以实现语义互操作。

SOA要实现互操作，就是通过一系列的标准族，来实现访问、连接和语义等各种层面的互操作。

软件复用

软件复用，即软件的重用，也叫再用，是指同一事物不作修改或稍加改动就多次重复使用。从软件复用技术的发展来看，就 是不断提升抽象级别，扩大复用范围。最早 的复用技术是子程序，人们发明子程序，就可以在不同系统之间进行复用了。但 是，子程序是最原始的复用，因为这种复用范围是一个可执行程序内复用，静态开发 期复用，如果子程序修改，意味着所有 调用这个子程序的系统必须重新编译、测试和发布。

SOA的复用

为了解决这个问题，人们发明了组件（或者叫控件），如MS操作系统下的DLL组件。组件将复用提升了一个层次，因为组件可以在一个系统内复用（同一种操作系统），而且是动态、运行期复用。这样组件可以单独发展，组件与组件调用者之间的耦合度降低。

为解决分布式网络计算之间的组件复用，人们发明了企业对象组件，如（Com+,.NET,EJB等)，或者叫分布式组件。通过远程对象代理，来实现企业网络内复用，不同系统之间复用。

传统架构的核心是组件对象的管理。但分布式组件也是严重依赖其计算环境，由于构件实现和运行支撑技术之间存在着较大的 异构性，不同技术设计和实现的构件之间无法直接组装式复用。

而现代SOA的重要特征就是以服务为核心，如WebService,SCA/SDO等。通过服务，或者服务组件来实现更高层次的复用、 解耦和互操作，即SOA架构中间件。

因为服务是通过标准封装，服务组件之间的组装、编排和重组，来实现服务的复用。而且这种复用，可以在不同企业之间，全球复用，达到复用的最高级别，并且是动态可配置的复用。

耦合关系

SOA架构在松耦合解耦过程也发展到了最后的境界。传统软件将软件之中核心三部分网络连接、数据转换、业务逻辑全部耦 合在一个整体之中，形成“铁板一块”的软件， “牵一发而动全身”，软件就难以适应变化。分布式对象技术将连接逻辑进行分 离，消息中间件将连接逻辑进行异步处理，增加了更大的灵活性。消息代理和一些分 布式对象中间件将数据转换也进行了分 离。而SOA架构，通过服务的封装，实现了业务逻辑与网络连接、数据转换等进行完全的解耦。

SOA不断解耦的过程

总之，从科学哲学的角度来看，SOA是一个不断解构的过程，传统软件强调系统性，耦合度过高，所以需要松耦合（解耦）；SOA也是一个组件粒度的平衡，集成电路趋势是集成度越来越高，软件发展的趋势是相反的过程；SOA是架构，更是 方法，反映了人们对哲学思想的追求的原动力。

按照这个特性，SOA基本上来说与WebService并不是同一个概念，SOA并不一定需要WebService实现，理论上可以在其他技 术体系下，实现SOA。但事实上，到目前为止，能够实现SOA架构风格的技术就是WebService，因为它的特性和厂商的支持 力度，使得WebService成为了实现SOA实现技术的事实标准。也正因为WebService技术的成熟，才使得已经提出10多年了的 SOA思想和概念，得以能够实现落地，成为一种可以使用的技术。这也就是回答了SOA和WebService的关系。

1.5 SOA服务架构开发趋势

传统汽车使用由上百个ECU组成的分布式EE架构，OEM定义对各ECU的功能需求，由不同供应商负责最终功能实现。这种架构导致大量功能控制逻辑在子节点ECU内部完成，传感器、执行器信号被掩埋在分布网络下，仅通过在局部网络的ECU部署基于服务的通讯，无法实现对整车硬件能力的充分暴露。且考虑到基于SOA软件平台，未来SOP后的车型也需具备硬件冗余能力以应对OTA软件升级，上百个ECU的冗余设计将极大增加成本支出，也导致跨域功能OTA的实现将涉及数量众多的ECU。
   随着车载芯片算力的提升和高带宽、低时延车载以太网通讯技术的落地，EE架构已从分布式演进至域集中 (Domain Centralized)，并向整车集中＋区域 (Vehicle Computer & Zonal)、整车集中 (Vehicle Centralized)不断进化。在高集成度的EE架构下，域控制器将承担整车主要逻辑，而执行器、传感器将成为纯粹的执行机构，执行控制命令或是提供环境感知数据。
   基于整车集中EE架构的“硬地基”， SOA在域控制器上的部署才能够实现整车能力的资源获取，并将其封装为标准的服务和接口向应用层开放。

1.6 SOA与E/E架构

1.6.1 域控制为核心的架构

电子电气架构的概念从总线引入汽车开始就不断更新和演化，如今一套完整的整车数字架构所考虑的内容除了传统的拓扑、网络、线束与电气分配、逻辑功能分配，还需结合整车的功能/信息安全架构、数据架构、计算架构，以及实现通讯架构与软件架构的协同，功能架构与服务架构的协同，车内服务与云端服务的协同。
如图所示：域集中架构在连接上由功能域控制器，分别通过子网与各功能域内ECU相连接，而域控制器之间则修建通讯“高速公路”，通过高带宽的骨干网络相连。拓扑结构只是架构的表象，而表象背后的核心特征是功能逻辑被抽象上移至功能域控制器中。每个域控制器有对应的集成的（Signal to Services）, 在域控制器中进行功能的分配、功能的集成。而某个域控制器作为云端链接的桥梁，将平行的几个域控制器的逻辑运算功能输入到云端。功能逻辑运算服务的重心在域控制器中。

1.6.2 区域控制为核心的SOA架构

如图所示：整车集中和区域架构在连接上是通过分布在车内各物理区域的区域网关/控制器将车内物理I/O分别就近连接和控制，形成整车数字系统的“手”和“脚”，然后通过骨干网络与系统中的“大脑”控制单元进行连接。连接关系同样只是表象，而核心价值在于将车内软件（运算）和硬件解耦，彻底实现软件独立“生长”（或者说算力架构可以迭代，共享算力变成了可能），而硬件同样可以独立“生长”（跨车型平台，或者在车辆生命周期内为用户提供升级服务，而这些在传统架构中实现的成本是不可控的）。

1.7 以服务为核心的SOA开发思路

虽然电子电气架构开发从理论上是正向开发，但实际上一款车型的开发并不是完全从零开始的，很多功能方案会沿用老款车型。这样的后果是，系统和软件模块已经固定，即无法通过正向设计的思路拆解逻辑，设计服务。考虑这种情况，服务设计可以分为以下两种方法。

(1)自下而上的方法

适用于现有平台上已实现的功能或系统。此种方法的基础是，功能的网络分配，通信，ECU软件架构，功能规范和使用场景等都已经有明确定义。我们可以利用现有的这些输入，完成将原有功能对SOA的转换。

适用功能和系统：

1. 车身舒适的大部分功能，如车门，车窗，座椅，空调等，功能逻辑没有太大争议，就可以通过现有子系统规范和网络信号清单，进行服务接口设计。
2. 动力和底盘系统。这是整车中对安全要求最高的两个系统，因此一般来说，我们在设计第一代SOA架构时。这两个系统更适合自下而上的方法，通过对已有功能的提取，转换为服务接口，接入整车服务系统。
3. 传感器和执行器资源。汽车上的每个元件都代表了一种基础能力。基于整车传感器和执行器清单，能够快速形成一份基础服务清单。由此出发，再通过功能梳理，层层往上，可以形成更加丰富多层次的服务列表。

(2)自上而下的方法

自上而下的方法即为正向设计方法。在基于SOA的电子电气架构开发中，对于复杂功能，或者引入到平台中的新功能和新系统，必须遵循这种方法完成服务设计。基于上述所介绍的开发流程，从需求出发，进行逻辑拆解，服务拆解，软件架构搭建，系统设计等。这个方法所依赖的输入一般是功能需求表和用户场景。

不管使用哪种方法，通常服务的设计是在单个功能或系统级别定义的，最后需要架构师综合考虑整车系统，将高度复用性的服务归类为平台级通用服务。通用服务池子是“生态共创”的基础。

服务的分类：

1. 硬件抽象服务根据ECU的功能和硬件外围设备（传感器和执行器），定义硬件抽象服务。这些服务同时属于平台级核心服务。示例：Camera interface，Rain sensor interface
2. 平台级核心服务在应用程序集群和域之间通用的所有服务。示例：Power mode，Vehicle speed，Key status
3. 域级核心服务在域内的应用程序集群内不同应用程序之间通用的服务。示例：Front vehicle distance calculate，Front obstacles
4. 应用服务为每个特定的应用程序或系统功能服务的服务。示例：Enable ACC，AEB system status

服务设计的输入要求：

(1)应用级别的服务

1. 功能和系统描述，用户场景描述
2. 功能和系统需求
3. 功能和系统逻辑架构

(2)平台级别的服务

1. 跨域的系统设计文档
2. 跨域的功能清单
3. 网络拓扑
4. 传感器和执行器列表（用于提取硬件抽象服务）

因此，服务设计的输出主要为：
(1)服务的定义

1. 服务接口的定义
2. 服务提供方和消费方信息
3. 软件模块信息

对应的输出文档可以分为：

1. 服务定义矩阵
2. 服务详细设计文档（包含软件实现信息）
3. 服务数据库ARXML（涵盖通讯、服务、软件部署等信息）

1.7.1 AP（Adaptive Platform）的开发

a. 定义服务内容

此步骤实际上就是搭建了一个系统功能架构，从整车层面即是按照功能需求定义并划分服务。对于SOA中的服务表示了一种独立的功能单元，一个服务可以包含其他子服务单元，使用标准接口进行通讯，将内部信息封装成一个黑盒子，实现子服务的重用性。上层服务可以通过该标准接口调用下层服务封装的子服务内容。同时，整体的服务内容可以被操控单元远程访问和独立更改或更新。同时，对于SOA来说，需要通过服务编排来定义清楚服务之间的相互关系。
简单地说服务对于智能驾驶汽车而言就是定义产品，对其中产品的能力进行描述，这里的产品能力我们称之为PC（Product Capability）。实现这种产品能力需要从下至上定义硬件抽象服务、平台核心服务、域核心服务、应用程序服务。而每一个服务内容对应着一个或多个实现的软件模块，这里我们称之为SWC（Software Capability）

产品能力 (PC) 描述了系统所需的一些高级功能。区别于系统设计，PC是用来分配职责的，所以很清楚哪个SWC Module软件模块（如摄像头识别模块、雷达识别模块、中央域控制器模块）应该实现什么。它们在功能设计时由功能负责人识别和请求。一些系统相关的PC也可以由系统架构师或模块负责人直接识别，在模块架构工作中映射PC时，模块所有者还可以确定对更多 PC 的需求。
在确定并决定添加 PC 后，对应的软件模块拥有该 PC，模块所有者负责将其实施到正确的版本，并在平台的整个生命周期内维护/发展 PC。

b. 定义服务接口

    服务接口是一种通信内容定义，其目的在于将服务从功能架构过渡到软件技术架构，且软件模块之间的关系需要被清晰的定义出来，过程中将服务内容封装成相应的接口被实际调用。这种接口定义是独立于通信协议的抽象实体，这种接口可以建立任何两个服务间的通信能力，而使用合适的工具链可以由此生成基于特定协议的接口。
服务接口可分为方法（Method）、属性（Property）、事件（Event）三种类型。以智能驾驶的一个子功能执行接口服务为例，假设需要获取摄像头传感器探测的环境数据，而需要进行定义的服务接口中方法是要对传感器的参数进行后融合，那么就需要其底层服务提供摄像头处理的基础函数（如ISP、深度学习函数、BEV函数等）。而服务接口的属性则是通过一定的方法操作（如get/set）来获取该服务函数，这种服务属性可以对上层调用的服务部分可见，底层服务有变动上层的调用方式也会随之变动，这种变动所带来的更新会由服务底层决定何时发送给上层调用它的服务单元。
服务接口定义完整后，开发人员可以根据该接口定义对其中的函数进行定义开发了。

c. 配置服务关系

    此过程会建立软硬件之间的映射关系，实现从抽象的服务定义到软件层面的推导，从而方便实现软件驱动或调用硬件实现单元，这种结果是实现服务与中间件或底层硬件ECU之间的映射关系。从整个SOA的架构模型中我们知道服务需要从通用服务平台开始进行底层驱动，然后对上层传感器执行器的控制管理进行驱动。由于AP直接支持服务接口，可以直接面向上层应用层，CP仍然是对常用的底层应用服务的驱动映射，因此，两层驱动分别对应着经典的CP Autosar中间件调用和AP Autosar模式。

d. 通讯协议设计

    智能网联汽车的SOA架构设计需要强大的环境感知、信息处理、实施决策、控制能力可以把智能交通、地图、定位、通讯、云、大数据等进行系统集成，故车端与云端、车辆与车辆之间、车辆内部的各个ECU之间通信的速率和数据量都比传统汽车高出几个数量级，这些需要由多种复杂的硬件、软件和高速通信总线共同实现，并在很大程度上决定智能汽车的功能实现和扩展的可靠性。车载以太网能够很好的解决大数据量的信息交互，整个通信协议的定义包括虚拟以太网VLAN，以太网交换机Switch，套接字Socket，基于IP的可扩展面向服务的中间件SOME/IP，SD等。而基于AVB的下一代协议TSN（时间敏感网络）可以提供非常优秀的实时性。

    以太网通讯设计过程包含对服务实例进行通讯协议相关的信息配置。由于SOA架构中包含多个应用实体之间的多通路通信过程，且这些通信通常是网状通信，因此需要在各个实体节点之间建立中间路由、转化等。区别于传统总线（Can/Lin），在软件架构设计过程中，开发人员需要设计具体的服务类型、服务ID、服务数据类型、服务角色等。

详细内容见下面链接：

汽车服务架构（SOA）开发设计https://download.csdn.net/download/ChrisKKC/82048291

【积分下载】软件定义汽车服务API-第一部分：原子服务API参考https://download.csdn.net/download/ChrisKKC/85089142【积分下载】软件定义汽车服务API-第一部分：原子服务API参考 变更说明https://download.csdn.net/download/ChrisKKC/85089150【积分下载】软件定义汽车服务API-第二部分：设备抽象API参考https://download.csdn.net/download/ChrisKKC/85089177【积分下载】软件定义汽车服务API-第二部分：设备抽象API参考变更说明1、软件定义汽车服务2、SOA架构3、API接口参考4、设备抽象API5、变更说明更多下载资源、学习资料请访问CSDN下载频道.https://download.csdn.net/download/ChrisKKC/85089158

1.什么是分布式架构

分布式系统（distributed system）是建立在网络之上的软件系统，它有两个特性：

• 1.内聚性
  数据库分布节点高度自治，有本地的数据库管理系统
• 2.透明性
  每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程

在分布式数据库系统中，用户感觉不到数据是分布的，即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。
简单来讲：在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的

在上图中，提到了一个SOA架构，那么这个SOA是什么呢？
这是一个主流的架构模型，与其功能类似也是我们经常听到用到的是微服务架构

2.SOA架构和微服务架构

2.1 SOA架构

SOA全称（Service Oriented Architecture） 中文意思为 面相服务的架构，他是一种设计方法，包含多个服务，服务之间通过相互依赖最终提供一系列的功能， 一个服务通常以独立的形式存在与操作系统进程中，各个服务之间通过网络调用

跟SOA相提并论的还有ESB（企业服务总线），简单来说ESB就是管道，链接各个服务节点，为了集成不同系统和不同协议，ESB做消息的转化解释和路由的工作。让不同的服务连通。
在未使用SOA架构时，系统初期：

随着业务的增长，系统后来就变成这个样子：

看起来是不是很糟糕，此时SOA架构应运而生，有了SOA之后就变成这个样子：

是不是看起来好多啦
分布式架构的设计思路就是当业务发展到一定程度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯。
面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障时会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。

所以SOA解决了：

• 1.系统集成，站在系统的角度，解决企业系统间的通信问题，把原先散乱无规划的系统间的网状结构，梳理成规划，可治理的系统间星型结构。 这一步需要引入一些产品，例如 ESB，以及技术规范，服务管理规范，这一步解决的核心问题是 有序
• 系统的服务化 ，站在功能的角度，把业务逻辑抽象成可复用可组装的服务，通过服务的编排和实现业务的快速再生，目的：把原先固有的业务功能变为通用的业务服务，实现业务逻辑的快速复用，这步解决的核心问题是 复用
• 3.业务的服务化,站在企业的角度，把企业只能抽象成可复用 可组装的服务，把原先职能化的企业架构转为变为服务花的企业架构，进一步提升企业的对外服务能力，前两步都是技术层面来解决系统调用，系统功能复用的问题，第三步 则是以业务驱动把一个业务单元封装成一项服务，这一步解决的核心问题是 高效

2.2 MSA 微服务架构

微服务是真正意义上的独立服务，从服务入口到数据持久层，逻辑上都是独立隔离的，无需服务总线来接入，但同时也增加了整个分布式系统的搭建和管理难度，需要对服务进行编排和管理，所以伴随着微服务的兴起，微服务生态的整套技术栈也需要无缝接入，才能支撑起微服务的治理理念。
微服务架构和SOA架构类似，微服务架构是在SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发设计运行的小应用。这些小应用之间通过服务完成交互和集成。
组件表示一个可以独立更换和升级的单元，像 PC机中的 CPU 内存，显卡 等 独立且可以更换升级而不影响其他单元，如果我们把PC机作为组件以服务的方式构建，那么这台PC只需要维护主板和一些必要的外部设备，CPU ，内存，硬盘 都是以组件方式提供服务，PC需要调用CPU做计算机处理，只需要知道CPU这个组件的地址即可。
如果一个分布式系统具备如下特点，则可以称之为“微服务架构”：

• 1、任何一个服务都由多个独立的进程提供服务，这些进程可以分布在多台物理机上，任何进程宕机都不会影响系统提供服务；
• 2、整个系统是由多个微服务有机组成的一个分布式系统，换而言之，不是一个巨大的单体应用。

微服务特征

• 1.通过服务实现组件化
• 2.按业务能力来划分服务和开发团队
• 3.去中心化
• 4, 基础设施自动化（devops ,自动化部署）

2.3 SOA 架构和微服务架构的区别

• 1，微服务不在强调传统的SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
• 2，Docker 容器技术的出现，为微服务提供了便利的条件，比如更小的部署单元，每个服务都可以通过类似的Node或者Spring boot 等技术跑在自己的进程中，
• 3，SOA 注重的系统集成方面，而微服务关注的是完全分离

提到分布式，就不得不说一下节点的概念

3.节点与网络

3.1 节点

传统的节点也就是一台单体的物理机，所有的服务都揉进去包括服务和数据库；
随着虚拟化的发展，单台物理机往往可以分成多台虚拟机，实现资源利用的最大化，节点的概念也变成单台虚拟机上面服务；
近几年容器技术逐渐成熟后，服务已经彻底容器化，也就是节点只是轻量级的容器服务。
总体来说，节点就是能提供单位服务的逻辑计算资源的集合。

3.2 网络

分布式架构的根基就是网络，不管是局域网还是公网，没有网络就无法把计算机联合在一起工作，但是网络也带来了一系列的问题。
网络消息的传播有先后，消息丢失和延迟是经常发生的事情，我们定义了三种网络工作模式：

• 同步网络

  • 节点同步执行
  • 消息延迟有限
  • 高效全局锁

• 半同步网络

  • 锁范围放宽

• 异步网络

  • 节点独立执行
  • 消息延迟无上限
  • 无全局锁
  • 部分算法不可行

常用网络传输层有两大协议的特点简介：

• TCP 协议
  • 首先 tcp 协议传输可靠，尽管其他的协议可以更快传输
  • tcp 解决重复和乱序问题
• UDP 协议
  • 常量数据流
  • 丢包不致命

4.分布式架构的演进

4.1 初始阶段

初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP

4.2 应用服务和数据服务分离

应用程序、数据库、文件分别部署在独立的资源上
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver

4.3 使用缓存改善性能

缓存是分布式系统中的重要组件，主要解决高并发，大数据场景下，热点数据访问的性能问题。
提供高性能的数据快速访问。你可以理解为从磁盘里取出来数据，暂时存放在内存，以待后面处理来读取。而能存放在缓存的数据，通常是频繁访问的，不会经常修改的数据。

系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。

数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力

对于不熟悉业务代码或算法的优化者，显然加一层缓存的复杂度和风险更低，而这一层看似简单的缓存，它给系统带来的性能优化有可能大大超过前者）
在WebServer和DB之间加一层cache，这层cache一般选取的介质是内存，因为我们都知道存入数据库的数据都具有持久化的特点，那么读写会有磁盘IO的操作，内存的读写速度远比磁盘快得多。（选用存储介质，提高访问速度：内存>>磁盘；减少磁盘IO的操作，减少重复查询，提高吞吐量）

缓存的业务场景

常见的缓存有：

• 1.浏览器缓存
  浏览器可以缓存一些静态资源，比如图片、js、css等，这些都是不常变化的内容，所以没有必要每次都去请求。（减少网络IO消耗，提高访问速度）
• 2.CPU缓存
  是位于CPU与内存之间的临时存储器，它的容量比内存小的多但是交换 速度却比内存要快得多。
• 3.数据库缓存
  • 将数据写入/读取速度更快的存储（设备）；
  • 将数据缓存到离应用最近的位置；
  • 将数据缓存到离用户最近的位置。

缓存系统常用的缓存淘汰策略：

• 1、Least Frequently Used（LFU）策略
  计算使用频率，优先淘汰最不常用的缓存条目，CPU的cache所采用的淘汰策略即为LFU策略；
• 2、Least Recently Used（LRU）策略–淘汰最近最少使用的条目；
• 3、Adaptive Replacement Cache（ARC）策略–该策略由两个LRU组成，第1个LRU包含的条目是最近只被使用过一次的条目，第2个LRU包含的是最近被使用过二次的条目；
• 4、其他还有一些基于缓存时间的淘汰策略，比如淘汰存活时间超过5分钟的缓存条目。

---

分布式缓存都采用Hash算法进行数据分片，将数量庞大的缓存项均匀分布到集群中的每个节点上，比如Redis3.0开始实现的分布式集群功能就采用了Hash算法，将缓存项均匀分布到16384个Slot上去。
以Redis2.x为基础改造的Codis是国内分布式缓存开源的一个典范，出自豆瓣网。
Memcache本身并没有提供集群功能，但很多客户端Driver实现了Hash算法分配逻辑，因此也可以看成是一种分布式缓存的解决方案。
内存计算产品：商业的SAP Hana、开源的VoltDB等。VoltDB是一种开源的高性能的内存关系型数据库，提供社区版和商业版，是一种NewSql，是一个借鉴并基于HSQL的分配内存数据库集群。
更多分布式缓存信息点击此处查看

4.4 应用服务集群

使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。

同时多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

4.5 数据库读写分离

享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢，至此我们可以通过设计数据集群，以及数据库的主从库，主负责写入，从库负责读取

4.6 反向代理和CDN加锁

为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。
不知道CDN是啥的，可以参考博文秒杀系统面试-2.1小节

4.7 分布式文件系统和分布式数据库

任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
常见的分布式缓存，数据库，文件系统如下：

4.8 通过DNS轮询实现机房间的负载均衡

在DNS服务器中可配置一个域名对应多个IP地址，每个IP地址对应到不同的机房里的虚拟IP。当用户访问www.taobao.com时，DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题。

4.9 引入noSQL和搜索引擎

当数据库中的数据多到一定规模时，数据库就不适用于复杂的查询了，往往只能满足普通查询的场景。对于统计报表场景，在数据量大时不一定能跑出结果，而且在跑复杂查询时会导致其他查询变慢，对于全文检索、可变数据结构等场景，数据库天生不适用。因此需要针对特定的场景，引入合适的解决方案。
如对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等方案解决，对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等方案解决。

下面我重点讲解一下nosql

nosql、sql

概念:

• SQL (Structured Query Language) 数据库，指关系型数据库。主要代表：SQL Server，Oracle，MySQL(开源),PostgreSQL(开源)。
• NoSQL（Not Only SQL）泛指非关系型数据库。主要代表：MongoDB，Redis，CouchDB。

两者的区别：

• 1.存储方式不同
  SQL数据存在特定结构的表中；
  NoSQL则更加灵活和可扩展，存储方式可以省是JSON文档、哈希表或者其他方式。
• 2.表/数据集合的数据的关系
  SQL：必须定义好表和字段结构后才能添加
  NoSQL:数据可以在任何时候任何地方添加，不需要先定义表
• 3.外部数据存储
  SQL：增加外部关联数据的话，规范化做法是在原表中增加一个外键，关联外部数据表。
  NoSQL中除了这种规范化的外部数据表做法以外，我们还能用如下的非规范化方式把外部数据直接放到原数据集中，以提高查询效率
• 4.SQL中的JOIN查询
  SQL中可以使用JOIN表链接方式将多个关系数据表中的数据用一条简单的查询语句查询出来。
  NoSQL暂未提供类似JOIN的查询方式对多个数据集中的数据做查询。所以大部分NoSQL使用非规范化的数据存储方式存储数据。
• 5.数据耦合性
  SQL中不允许删除已经被使用的外部数据
  NoSQL中则没有这种强耦合的概念，可以随时删除任何数据。
• 6.事务
  SQL中如果多张表数据需要同批次被更新，即如果其中一张表更新失败的话其他表也不能更新成功。这种场景可以通过事务来控制，可以在所有命令完成后再统一提交事务。
  NoSQL中没有事务这个概念，每一个数据集的操作都是原子级的。
• 7.增删改查语法不同
• 8.查询性能不同
  在相同水平的系统设计的前提下，因为NoSQL中省略了JOIN查询的消耗，故理论上性能上是优于SQL的。

搜索引擎

• Lucence Core：Java编写的核心类库，提供全文检索功能的底层API与SDK。
• Solr：基于Lucence Core开发的高性能搜索服务，提供了REST API的高层封装接口，还提供了一个Web管理界面。
• PyLucene：一个Python版的Lucene Core的高仿实现。
• ElasticSearch：也是基于Lucence的分布式全文检索中间件。

4.10 业务拆分

系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

• 纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统
• 横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务

4.11 复用的功能抽离成微服务

如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。
此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。

4.12 引入企业服务总线ESB屏蔽服务接口的访问差异

通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务，服务与服务之间也通过ESB来相互调用，以此降低系统的耦合程度。
这种单个应用拆分为多个应用，公共服务单独抽取出来来管理，并使用企业消息总线来解除服务之间耦合问题的架构，就是所谓的SOA（面向服务）架构，这种架构与微服务架构容易混淆，因为表现形式十分相似。
微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想，而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想，SOA架构中包含了微服务的思想。

业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难

4.13 引入容器化技术实现运行环境隔离与动态服务管理

目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes(K8S)，应用/服务可以打包为Docker镜像，通过K8S来动态分发和部署镜像。
Docker镜像可理解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实际的需要设置好。
把整个“操作系统”打包为一个镜像后，就可以分发到需要部署相关服务的机器上，直接启动Docker镜像就可以把服务起起来，使服务的部署和运维变得简单。

在大促的之前，可以在现有的机器集群上划分出服务器来启动Docker镜像，增强服务的性能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响。

4.14 以云平台承载系统

系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合Docker和K8S来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。

所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。在云平台中会涉及如下几个概念：

• IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
• PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
• SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。

至此，以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案，但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题。

5.分布式服务可能会面临的问题

• 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
• 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系.
• 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
• 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？

6.分布式事务

在了解分布式事务之前，我先引入一个概念：时间与顺序

6.1 时间

对于串行的事务来说，很简单的就是跟着时间的脚步走就可以，先来后到的发生。而后我们发明了时钟来刻画以往发生的时间点，时钟让这个世界井然有序。但是对于分布式世界来说，跟时间打交道着实是一件痛苦的事情。
分布式世界里面，我们要协调不同节点之间的先来后到关系，不同节点本身承认的时间又各执己见，于是我们创造了**网络时间协议（NTP）**试图来解决不同节点之间的标准时间，但是 NTP 本身表现并不尽如人意，所以我们又构造出了逻辑时钟，最后改进为向量时钟：

• NTP 的一些缺点，无法完全满足分布式下并发任务的协调问题
  • 节点间时间不同步
  • 硬件时钟漂移
  • 线程可能休眠
  • 操作系统休眠
  • 硬件休眠

• 逻辑时钟
  • 定义事件先来后到
  • t’ = max(t, t_msg + 1)
    
• 原子钟

6.2 顺序

有了衡量时间的工具，解决顺序问题自然就是水到渠成了。
因为整个分布式的理论基础就是如何协商不同节点的一致性问题，而顺序则是一致性理论的基本概念。
有了上面信息的一些基础认知之后，我们开始正式描述分布式的事务理论

6.3 一致性理论

主要通过三个非常重要的理论来进行刻画

• 1.强一致性 ACID
• 2.分布式一致性 CAP
• 3.弱一致性 BASE

首先我们先看一下ACID理论

数据库本地事务：强一致性 ACID

单机环境下我们对传统关系型数据库有苛刻的要求，由于存在网络的延迟和消息丢失，ACID 便是保证事务的原则，这四大原则便是：

• Atomicity：原子性，一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节；保证了事务操作的整体性
  Consistency：一致性，在事务开始之前和事务结束以后，数据库的完整性没有被破坏；事务操作下数据的正确性
  Isolation：隔离性，数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时，由于交叉执行而导致数据的不一致；保证了事务并发操作下数据的正确性
  Durabilit：持久性，事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。保证了事务对数据修改的可靠性

请大家务必牢记
ACID是数据库的本地事务，而事务的ACID是通过InnoDB日志和锁来保证

• 事务的隔离性是通过数据库锁的机制实现的
• 持久性通过redo log（重做日志）来实现
• 原子性和一致性通过Undo log来实现

分布式事务理论–CAP

• Consistency：一致性,数据一致更新，所有数据变动都是同步的。
• Availability：可用性，好的响应性能，非故障的节点在合理的时间内返回合理的响应。
• Partition tolerance：分区容错性，可靠性当出现网络分区后，系统能够继续工作。

分布式系统理论上不可能选择 CA （一致性 + 可用性）架构，只能选择 CP（一致性 + 分区容忍性） 或者 AP （可用性 + 分区容忍性）架构，在一致性和可用性做折中选择。

另外，只能选择CP或者AP是指系统发生分区现象时无法同时保证C（一致性）和A（可用性），但不是意味着什么都不做，当分区故障解决后，系统还是要保持保证CA

弱一致性 BASE

多数情况下，其实我们也并非一定要求强一致性，部分业务可以容忍一定程度的延迟一致，所以为了兼顾效率，发展出来了最终一致性理论 BASE。BASE 是指

• BA：基本可用（Basically Available），分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用；
• S：软状态（ Soft State），允许系统存在中间状态，而该中间状态不会影响系统整体可用性。
• E：最终一致性（ Eventual Consistency），最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

CAP 理论是忽略延时的，而实际应用中延时是无法避免的，这一点就意味着完美的 CP 场景是不存在的，即使是几毫秒的数据复制延迟，在这几毫秒时间间隔内，系统是不符合 CP 要求的。因此 CAP 中的 CP 方案，实际上也是实现了最终一致性，只是“一定时间”是指几毫秒而已。
同时方案中牺牲一致性只是指发生分区故障期间，而不是永远放弃一致性，这一点其实就是 BASE 理论延伸的地方，分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。
总结： BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

强一致性、弱一致性、最终一致性

• 强一致性
  要求无论更新操作是在哪个数据副本上执行，之后所有的读操作都要能获得最新的数据。
  对于单副本数据来说，读写操作是在同一数据上执行的，容易保证强一致性。对多副本数据来说，则需要使用分布式事务协议。
• 弱一致性
  在这种一致性下，用户读到某一操作对系统特定数据的更新需要一段时间，我们将这段时间称为"不一致性窗口"。
• 最终一致性
  它是弱一致性的一种特例，在这种一致性下系统保证用户最终能够读取到某操作对系统特定数据的更新（读取操作之前没有该数据的其他更新操作）。"不一致性窗口"的大小依赖于交互延迟、系统的负载，以及数据的副本数等。

有了这些分布式事务的理论，我们再接着聊聊分布式事务解决方案

6.4 分布式事务解决方案

2PC方案

二阶段提交协议（Two-phase Commit，即2PC）是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。

• 准备阶段：
  协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
  各参与者执行事务操作，将undo和redo信息记入事务日志中（但不提交事务）。
  如参与者执行成功，给协调者反馈yes，即可以提交；如执行失败，给协调者反馈no，即不可提交。
• 提交阶段：
  如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。

核心思想就是对每一个事务都采用先尝试后提交的处理方式，处理后所有的读操作都要能获得最新的数据，因此也可以将二阶段提交看作是一个强一致性算法。
简单理解就是：

• 第一阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交
• 第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据

但是2PC方案也会面临很多问题

• 单点问题:事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。
• 同步阻塞:在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。
• 数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。

7.架构设计总结

• 架构的调整是否必须按照上述演变路径进行？

  不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。

• 对于将要实施的系统，架构应该设计到什么程度？

  对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。

• 服务端架构和大数据架构有什么区别？

  所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术，如:

  • 数据采集有Flume、Sqoop、Kettle等
  • 数据存储有分布式文件系统HDFS、FastDFS
  • NoSQL数据库HBase、MongoDB等
  • 数据分析有Spark技术栈、机器学习算法等。

  总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。

8.分布式架构设计原则

• N+1设计。系统中的每个组件都应做到没有单点故障；
• 回滚设计。确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
• 禁用设计。应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
• 监控设计。在设计阶段就要考虑监控的手段；
• 多活数据中心设计。若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
• 采用成熟的技术。刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
• 资源隔离设计。应避免单一业务占用全部资源；
• 架构应能水平扩展。系统只有做到能水平扩展，才能有效避免瓶颈问题；
• 非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
• 使用商用硬件。商用硬件能有效降低硬件故障的机率；
• 快速迭代。系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
• 无状态设计。服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。

至此分布式的基础理论就到此结束啦，接下来我们谈一谈分布式在具体通过业务场景浅谈分布式设计思路