一，前言

之前买的cocos2dx游戏都是单机版本的，不是联机版本，所以我在想联机版本的服务器和客户端游戏他们应该是如何设计的呢！那么就引发我思考现在有些互联网的架构设计都已经跨界到汽车行业了，在软件定义汽车的说法中，最热门的就是可插拔松耦合的微服务架构。按我以前理解的就想我学习过了机器人ROS操作系统中的client/server，也和autosar developer的client/server类似，或者也和MQTT的订阅和发布c/s类似的软件设计就是微服务。

所以我理解，对我这个经常学习跨界技能的人来说，微服务没有什么新颖，与传统汽车软件架构来说，单独的ecu不是通过can总线进行数据交互，而是c/s命令交互。各ecu的交互更新开放自由了，都已经整合到软件api接口了。但是说到分布式和集群让我解释，我好像说不清楚了，所以要了解下。

二，基础知识

1，分布式和微服务区别

分布式：将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。
微服务：将模块拆分成一个独立的服务单元通过接口来实现数据的交互。
微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。分布式和微服的架构很相似，只是部署的方式不一样而已。分布式的特点是分散压力，微服务的特点分散能力。

2.分布式和集群区别

再看看分布式和集群，分布式是一个业务分拆多个子业务，部署在不同的服务器上。集群是同一个业务，部署在多个服务器上。
分布式的每一个节点，都完成不同的业务，一个节点垮了，那这个业务就不可访问了。分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

三，将架构设计思想融会贯通到汽车整车ECU开发中

分布式还有集群好像直接说的都是PC服务器。那么把每个PC服务器，想象为每个汽车零部件ECU，这样来看，从汽车整车的角度去思考，传统汽车就是分布式开发，每个ecu零部件负责汽车中的一个功能，比如仪表负责显示，而空调负责控制温度等。他们各自都是黑盒的，至少软件api不开放，所谓的交互接口就是can/lin/以太网总线数据。而要是改成微服务设计方式，那么我理解can/lin/以太网交互的数据就会变成命令，而非我们以前数据矩阵表中传递的内容了。

四，微服务的实现方法：RPC和事件驱动

1. RPC

我之前调试uboot中以太网功能的时候看到了rpc，所以了解过RPC（Remote Procedure Call Protocol）——远程过程调用协议，RPC简单的来说就是像调用本地服务一样调用远程服务。好像jlink的openOCD也用到这类设计思想。远程发命令但是在本地调用命令执行。就是用了RPC。所以RPC可以算是符合微服务设计，但是耦合性强，因为调用的话，则立即返回server执行结果。

2. 事件驱动

事件驱动就是发消息，给具体对象发消息或者广播，有一个专门处理消息的对象，然后ecu会从此对象中接收消息。咋一看是否觉得和我在大屏仪表c++代码中设计思路一个样子。在大屏仪表c++的设计中，用了linux中多进程的消息传递，用到了单播和广播。而这里说的事件驱动的对象不是一个汽车ECU中不同软件模块的交互，而是一个整车中每个ECU的交互。对象不同了，但是方法一样。

五，总结

有时候所谓的创新就是跨界融合。把电子行业和生物行业融合，就有了仿生电子心脏。所以我喜欢学习跨界的东西，很多创造的灵感就是通过跨界的技能通过深度思考融合而来的。要进步就要不断思考总结，取其精华去其槽粕，多学习可迁移的技能可以事半功倍。啊哈~