引言：
我们是车载以太网小L，深耕于整车以太网架构系统设计和软件开发，入过很多坑，尤其是SOA架构，没有经验可以借鉴，一路过关斩将，摸着石头过河，可谓经历九九八十一难，有一堆的经验和心得，想和行业内同仁分享和探讨，如果能够帮助大家解决一些实际问题，那将是我分享的意义所在，喜欢的话，记得关注我哦
《浅谈整车SOA架构》系列分为四大部分，层层递进，干活满满，千万不要错过哦：
1. 背景介绍
2.大家眼中的SOA
3.我眼中的SOA
4.整车SOA系统设计分享
背景介绍
首先让我们从背景介绍作为切入点，来介绍SOA。在开始之前，需要跟大家交代一下SOA的相关概念定义。
01
定义
中间件：一种独立的系统软件服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。
SOME/IP：Scalable service-Oriented MiddlewarE over IP，一种中间件，在传输层UDP/TCP协议基础之上，应用层之下的特定协议，拥有特定的服务交互机制，服务上线后广播告知域内其他节点，其他节点收到服务广播后，请求或者订阅相关服务接口。
HTTP：互联网常用的服务协议，使用GET/POST等机制来获取或者设置相关数据。在汽车行业内，一般用于车内节点和云端无线通信协议，传输大于10MB的数据
MQTT：互联网常用的服务协议，基于订阅和发布机制来获取或者设置相关数据。在汽车行业内，一般也用于车内节点和云端无线通信协议，传输小于10MB的数据。
HTTP，MQTT和SOMEIP均用于实现SOA架构的通信，只是负责的场景不同，SOME/IP协议用于车内节点之间的服务通信，HTTP/MQTT用于和互联网模块通信，三者实现机制相类似，可以相互切换。
服务：
互联网概念：应用了面向对象服务之后的具有丰富外延(API)的逻辑单元，通过发布服务接口的方式使其功能对外可见的软件程序
Classic AUTOSAR概念：提供一个或多个服务接口的功能实体；
自己的理解：汽车行业内，将最小功能逻辑单位封装成服务，通过调用服务接口，来实现不同功能逻辑模块的相互交互，实现数据交互。
SOA：
是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。——百度百科
一种粗粒度小、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型
需要注意的是，SOA架构并不仅限于HTTP、MQTT、SOME/IP协议来实现
Hybervisor：
提供平台虚拟化，通过某种方式隐藏底层物理硬件的过程，从而让多个操作系统可以透明地使用和共享它；
URL：
在WWW上，每一信息资源都有统一的且在网上唯一的地址，该地址就叫URL（r,统一资源定位符），它是WWW的统一资源定位标志，就是指网络地址。
电子电器架构
对于整车电子电器架构的发展以及趋势，网络上有各种分享，这边就不做累述了， 大家可自行百度。
不管是域控制器电子电器架构还是Zonal电子电器架构都依托于SOA架构理念。因为SOA架构的软硬件解耦，所以这两种架构的SOA设计理念是完全相同，并且可以相互复用，所以在推广和设计新型电子电器架构的，落实好SOA理念，对于发挥架构的优势至关重要。
互联网SOA理念
互联网对SOA架构的定义是一种架构思想，并没有公认的定义，从不同的方面来进行描述，有的说SOA是一种应用程序架构，所有功能都定义为独立的服务，这些服务有非常明确的可以被调用的服务接口，能够按约定好的顺序调用这些服务接口来实现业务流程，有的还说服务需要精准定义，非常完备的封装，是服务间非常独立的函数，其实SOA本质上是服务的集合，服务与服务之间可以相互调用和通信，可以是简单的数据传输或者服务之间协作完成某些操作功能，还有的说SOA是一种基于客户端和服务端模式的架构软件设计方法，应用由服务和它的使用者组合而成，它特别注重服务所对应的组件之间的松耦合性，所有的接口都是标准化，独立化。
通过前辈的总结，不难发现SOA的实现是多元化的，同理SOA架构下的通信协议是多元化的，任何基于服务机制的协议均可以认为是SOA架构通信协议。但是汽车行业，运用比较广泛的主要是HTTP、MQTT和SOME/IP协议，其中SOME/IP是满足车规要求，而HTTP和MQTT承接与互联网，多运用于无线网络，以便于车内节点和云端交互，但也可以用于车内有线以太网，由此可见通信协议不是重点，基于服务通信的理念是SOA架构得以发展的精髓。
在正式讲解整车SOA架构之前，我们先介绍一下HTTP和MQTT，让大家对SOA架构的通信机制有一个初步了解。HTTP和MQTT都是互联网SOA架构服务通信协议，那如何选择呢，请关注后续《整车SOA系统设计分享》章节详细介绍。
1.HTTP
HTTP作为超文本传输协议，标准为RFC1945和RFC 2616(版本不同)，众所周知是用于从WWW服务器传输超文本到本地浏览器的一种非常常用的应用层协议，基于请求和响应的通信机制，之所以说它是应用层协议，是因为HTTP协议是位于TCP协议之上。这里请注意，基于TCP传输，那TCP必须基于三次握手，才能实现客户端和服务器之间的数据传输。(三次握手机制请自行百度)
这里有个疑问，为什么我们浏览网页的时候经常看到的是https字符？肯定有好多人跟我有一样的想法吧，后来了解才知道是因为在TCP和HTTP协议之间引入TLS信息安全协议后，才成为HTTPS。
基于请求和响应的通信机制，所有的通信是客户端发起请求，服务器针对请求作出对应的响应，因此如果客户端没有发起请求的话，服务器就无法主动给客户端发送消息。这里考大家一个问题，如果我们一定要实现服务器主动发送消息给客户端，那该如何用HTTP来实现呢？（后续文档中解答，敬请关注 ）
两种最常用的HTTP服务接口是GET和POST，其中GET是客户端从指定的服务器资源中请求数据，POST则是向指定的服务器资源提交要被处理的数据。
下面详细的介绍下这两种服务接口。
Get：
如果当客户端要从服务器中读取相关数据时，使用的都是GET方式。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，以响应的形式返回给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号‘？’代表URL的结尾与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。通过GET方式传递的数据直接放在地址中，所以GET方式的请求一般不包含“请求内容”部分，请求数据以地址的形式表现在请求行。地址中‘？’之后的部分就是通过GET发送的请求数据，各个数据之间用‘&’符号隔开。另外，由于不同的浏览器对地址的字符限制也有所不同，一半最多只能识别1024个字符，所以如果需要传送大量数据的时候，也不适合使用GET方式。如果数据是英文字母/数字，原样发送；如果是空格，转换为+；如果是中文/其他字符，则直接把字符串用BASE64加密，得出：%E4%BD%A0%E5%A5%BD，其中%XX中的XX为该符号以16进制表示的ASCII。
POST：
POST允许客户端给服务器提供信息较多。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，这样POST方式对传送的数据大小没有限制，而且也不会显示在URL中。POST方式请求行中不包含数据字符串，这些数据保存于“请求内容”部分，各数据之间也是使用‘&’符号隔开。POST方式大多用于页面的表单中。因为POST也能完成GET的功能，因此多数人在设计表单的时候一律都使用POST方式，其实这是一个误区。GET方式也有自己的特点和优势，我们应该根据不同的情况来选择是使用GET还是使用POST。
2.MQTT
MQTT，全称为消息队列遥测传输协议，位于TCP/IP协议簇之上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布订阅型的消息中间件，轻量、简单、开放和易于实现，是它的主要亮点，也直接决定了它的运用非常广泛。
在介绍MQTT的发布订阅型，必须要先明确一下通信角色。MQTT进一步细化了服务器和客户端的模式，采用的是Client和Broker，如下图所示，发布和订阅者均为Client，而服务器端则成为Broker。
Broker类似一个猎头的作用，会在各个企业中收集岗位信息，根据岗位主题Topic来过滤分类不同的岗位，并根据客户端需求推送给相关信息，比如某个订阅者告诉Broker，凡是涉及SOA软件开发工程师招聘消息都发给自己(订阅行为)，之后某个发布者有一个SOA软件开发工程师岗位发布给猎头Broker，岗位主题就是SOA软件开发工程师招聘，发布的内容是本月30号面试，这样Broker收集和整合发布和订阅者的梦需求者，作为猎头，需要将发布的内容给到需要的订阅者手上，因此不管是发布者还是订阅者，都不知道对方的身份，只需要将相关topic的消息发送给Broker，由Broker来代理和整合过滤，间接完成订阅和发布相关交互。
看到这边，大家也肯定同样的疑问，MQTT只有发布和订阅，是如何做到类似HTTP的GET和POST机制呢，这个问题同样参看后续文章《浅谈SOA架构系统设计——整车SOA系统设计》
综上，HTTP和MQTT已经有了一个初步的认识，请大家牢记，整车SOA架构都是基于服务器和客户端展开，服务接口也都是GET，SET，订阅和发布。
请大家继续关注《浅谈整车SOA架构》第2篇 大家眼中的SOA