背景介绍

未来的多电子设备协作对系统在功能升级，设备资源调整的持续集成和动态自适配能力上要求越来越高。

1. 功能升级包括应用程序、Sos(服务管理系统)等；

1. 设备资源调整包括网关服务节点、节点服务升级、节点外设增删等。

不仅限于上述场景，都要求系统架构在设计开发、集成、系统运行、多设备协作等方面有超高的灵活性。

以前单Master的系统架构要转向多智体灵活协作的模式。

需求分析

从垂直方向看，应用程序运行时占用了相关服务组件，其自身是Master组件唯一或者之一。

其所有的运行时组件可能分布到系统中各个设备上去，而且不仅可以通过应用程序系统或者设备网络系统的实时情况做最优调整，也可以通过用户指定分派。

设计或者运行时期望应用程序本身或者依赖的服务组件都可以灵活的分配和重分配，分配策略也是可以灵活升级，而且可选可配。

分派策略优先考虑用户指定，然后考虑系统优化。

 

设备服务化分析

网络Sos是抽象概念，是各设备Sos（private）和Sos（public）的集合。

App可以动态部署的不仅仅是执行端services（包括UI显示），也可以是App自己（master）。

Sos的调度公有策略应该考虑，网络中计算能力、内存部署、通讯延迟、通讯带宽等，而且应该有多种策略可选。

而用户可以定制配置私有服务调度倾向。

Sos的服务资源管理、根据App服务请求的服务App链接管理:

 

硬件抽象层：

不是所有硬件都必须独立完成服务抽象，可以形成一个Ap设备管理多个Cp设备，然后整体服务化。

网络服务化分析

首先设备服务化是目前大家解耦过分复杂的硬件环境的手段，将每个设备抽象成私有或者公有服务（共识协议）。

用户端应用开发和系统集成都建立在服务资源的基础上，在服务层形成共识。

 

App Cluster：来自于设备网络中每个设备用户端应用的全集；

Service Cluster：来自于设备网络中每个设备的服务抽象的全集，包括设备间公有服务和设备内私有服务；

注：App Cluster和Service Cluster允许升级、扩展、删减等等操作。

Sos：管理Service Cluster的资源，并按照预定策略和用户动态设置分配服务给App（或者可以App（宏观理解为应用层控制管理模块和服务组件）在服务资源网络上的部署）。

 

服务和协作共识分析

服务通过标准接口向设备注册服务；

设备通过标准接口向系统注册设备和提供服务；

设备都可以装载公有的标准服务管理模块；

服务通过类型分类，被不同的管理模块管理；

多设备相同服务管理模块可以自动协作和同步信息；

服务管理模块向Sos调度提供服务状态信息；

一个设备可以拥有多个不同服务管理模块；

多设备协作管理服务资源，自适配的统筹并为Sos的分派调度服务；

Sos不需要了解服务的细节，只要能负责好中介职能即可；

如果当前设备并不拥有其装载的某个应用的某个依赖服务管理模块，可以跨模块支持，也可以镜像一份。

设备网络通过共识让相同的服务协作。

灵活性分析

1. App服务请求网络

无论网络中AppCluster发生什么变化，都会被App服务请求管理映射到设备网络上。

1. 服务资源管理网络

无论网络中Service发生什么变化，都会被服务资源管理映射到设备网络上。

1. App&Service链接管理

通过面向服务的公有调度策略和面向用户配置的私有调度策略，灵活的适配各种应用场景的不同需求。

1. 灵活性降级

上述架构拥有很高的灵活性，但是如果在链接指定或者写死的情况下，还有某些策略绝对不会被使用情况下，可以在release时将部分策略去掉，甚至直接写死，降低cpu和内存开销。