目录
一、鸿蒙操作系统架构案例分析
1.1 鸿蒙操作系统定义
1.2 鸿蒙的层次化分析
1.2.1 内核层
1.2.2 系统服务层
1.2.3 框架层
1.2.4 应用层
1.3 鸿蒙操作系统的架构分析
1.3.1 鸿蒙操作系统架构具有4个技术特性
1.3.2 分布式架构所带来的优势
1.3.3 HarmonyOS 架构的系统安全性
二、面向安全攸关系统的跨领域 GENESYS 系统架构案例分析
2.1 GENESYS 定义
2.2 GENESYS 架构
2.3 GENESYS基于消息的构件接口
2.4 GENESYS 三级集成
往期推荐
一、鸿蒙操作系统架构案例分析
1.1 鸿蒙操作系统定义
鸿蒙操作系统 (HarmonyOS) 是华为公司研制的一款自主版权的操作系统，是一款“面向未来”、面向全场景(移动办公、运动健康、社交通信、媒体娱乐等)的分布式操作系统。在传统的单设备系统能力的基础上， HarmonyOS 提出了基于同一套系统能力、适配多种终端形态的分布式理念，能够支持多种终端设备的能力。
鸿蒙 (HarmonyOS) 整体采用分层的层次化设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统”→“子系统”→“功能/模块”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或功能/模块，如下图所示：
1.2 鸿蒙的层次化分析
1.2.1 内核层
内核层主要由内核子系统和驱动子系统组成。
内核子系统： HarmonyOS 采用多内核设计，支持针对不同资源受限设备选用适合的 OS 内核。内核抽象层 (Kernel Abstract Layer,KAL)通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。
驱动子系统：HarmonyOS 驱动框架 (HDF) 是HarmonyOS 硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架。
1.2.2 系统服务层
系统服务层是HarmonyOS 的核心能力集合，通过框架层对应用程序提供服务。该层包含4个部分：系统基本能力子系统集、基础软件服务子系统集、增强软件服务子系统集和硬件服务子系统集。
系统基本能力子系统集：为分布式应用在 HarmonyOS 多设备上的运行、调度、迁移等操作提供了基础能力。
基础软件服务子系统集：为HarmonyOS 提供公共的、通用的软件服务。
增强软件服务子系统集：为HarmonyOS 提供针对不同设备的、差异化的能力增强型软件服务。
硬件服务子系统集：为HarmonyOS 提供硬件服务。
1.2.3 框架层
框架层为HarmonyOS 的应用程序提供了Java/C/C++/JS 等多语言的用户程序框架和Ability框架，以及各种软硬件服务对外开放的多语言框架API；同时为采用HarmonyOS 的设备提供了C/C++/JS 等多语言的框架API, 不同设备支持的 API与系统的组件化裁剪程度相关。
1.2.4 应用层
应用层包括系统应用和第三方非系统应用。 HarmonyOS 的应用由一个或多个 FA(Feature Ability)或PA(Particle Ability) 组成。其中， FA 有 UI界面，提供与用户交互的能力；而PA 无UI界面，提供后台运行任务的能力以及统一的数据访问抽象。基于FA/PA 开发的应用，能够实现特定的业务功能，支持跨设备调度与分发，为用户提供一致、高效的应用体验。
1.3 鸿蒙操作系统的架构分析
1.3.1 鸿蒙操作系统架构具有4个技术特性
（1）分布式架构首次用于终端 OS,实现跨终端无缝协同体验。
（2）确定时延引擎和高性能 IPC 技术实现系统天生流畅。
（3）基于微内核架构重塑终端设备可信安全。
（4）通过统一 IDE 支撑一次开发，多端部署，实现跨终端生态共享。
1.3.2 分布式架构所带来的优势
在HarmonyOS 架构中，重点关注于分布式架构所带来的优势，主要体现在分布式软总线、分布式设备虚拟化、分布式数据管理和分布式任务调度等四个方面。
分布式软总线是多种终端设备的统一基座，为设备之间的互联互通提供了统一的分布式通信能力；
分布式设备虚拟化平台可以实现不同设备的资源融合、设备管理、数据处理，多种设备共同形成一个超级虚拟终端。针对不同类型的任务，为用户匹配并选择能力合适的执行硬件；
分布式数据管理基于分布式软总线的能力，实现应用程序数据和用户数据的分布式管理。用户数据不再与单一物理设备绑定，业务逻辑与数据存储分离，应用跨设备运行时数据无缝衔接，为打造一致、流畅的用户体验创造了基础条件；
分布式任务调度基于分布式软总线、分布式数据管理、分布式 Profle等技术特性，构建统一的分布式服务管理(发现、同步、注册、调用)机制，支持对跨设备的应用进行远程启动、远程调用、远程连接以及迁移等操作，能够根据不同设备的能力、位置等选择合适的设备运行分布式任务。
1.3.3 HarmonyOS 架构的系统安全性
HarmonyOS 架构的系统安全性主要体现在搭载HarmonyOS 的分布式终端上，可以保证
“正确的人，通过正确的设备，正确地使用数据”。
通过“分布式多端协同身份认证”来保证“正确的人”；
通过“在分布式终端上构筑可信运行环境”来保证“正确的设备”；
通过“分布式数据在跨终端流动的过程中，对数据进行分类分级管理”来保证“正确地使用据”。
二、面向安全攸关系统的跨领域 GENESYS 系统架构案例分析
2.1 GENESYS 定义
GENESYS(GENeric Embedded SYStem) 是一种跨领域的通用嵌入式架构平台。主要解决了当时嵌入式系统所面临的三方面挑战：
复杂性管理的挑战(采用消息交换方式实现软硬件构件的抽象级别的提升)；
系统健壮性的挑战(设计出故障或错误的隔离框架)；
能量有效使用的挑战(采用综合化资源管理方法)。
GENESYS 整个架构包括两类构成系统：即构件和基础平台。基础平台提供了一种“腰”型核心服务和大量用于实现系统构件的可选择服务的最小集合。
如上图所示，GENESYS 架构主要提供了三组服务，即领域无关服务、领域专用服务和应用专用服务(包括中间件)。领域无关服务又分为核心服务和选择服务；领域专用服务又分为领域专用中心服务 (DSC) 和领域专用选择服务 (DSO)。
（1）核心服务。核心服务是强制性的，是GENESYS 架构实例的一部分。核心服务应包含那些可构造较高级服务或者为了维持该结构性质而不可缺少的服务，它是系统服务中的最小集。
（2）选择服务。选择服务是在核心服务之上构造的。它是一种需要时可以扩展的开放式的集合。
（3）领域专用服务。领域专用服务是由领域特有的选择服务子集加上待开发的领域特征的特定服务组合。
2.2 GENESYS 架构
GENESYS 架构的重要思想是分离计算与通信，将计算构件和通信设施作为独立构件进行
设计。
GENESYS 的通信设施构件是基于消息传输的风格。构件中的基本交往机制是多播单向
消息的交换。消息在发送时刻发出，在某个稍后的时刻达到在接收者那里。每一个消息有专门
标识的发送者和若干个接受者。
GENESYS 架构将构件归为四类：硬件构件和软件构件、系统构件和应用构件。
● 硬件构件的功能使用硬件(如ASIC) 被预先确定，因此不能修改。
● 在软件构件中，将加载在软件构件上的软件称为作业。将作业分配给适当的可以执行该作业的硬件单元就创建了新的构件。
● 系统构件是提供某些架构服务的构件。
● 应用设计者只考虑应用构件的开发。
2.3 GENESYS基于消息的构件接口
基于GENESYS 架构的四类基于消息的构件接口。如下图所示：
链接接口 (LIF)：LIF提供了构件与构件之间基于消息的操作服务，它是构件的综合接口。
局部接口 (LI)：LI是构件连接到外部环境(如I/O、 其他系统)的接口，它建立了构件和局部环境之间的连接关系。
技术无关接口 (TII)：TII是指用于系统运行需要的配置或管理资源的接口，它属于非功能属性范畴。
技术相关的接口 (TDI)：TDI是指用于查看构件内部、观察构件的内部变量的接口，如构件诊断。
2.4 GENESYS 三级集成
GENESYS 定义了三级的集成，即芯片级 (Chip Level)、设备级 (Device Level)和系统级 (System Level)。
芯片级的构件是 IP核，IP 核间可通过 NoC(Network of Chip)相互连接；
设备级的构件是芯片，芯片间可以由内部通信芯片互相连接。一个设备可以是在互联网上的一个可寻址实体，也可以是一个IP 地址；
系统级的构件是设备，它们可以由有线或无线通信服务互相连接。
往期推荐
【系统架构设计师】二十二、嵌入式系统架构设计理论与实践①-CSDN博客文章浏览阅读310次，点赞10次，收藏11次。嵌入式操作系统 (Embedded Operating System,EOS)是指用于嵌入式系统的操作系统。通常包括与硬件相关的底层驱动软件、系统内核、设备驱动接口、通信协议、图形界面、标准化浏览器等。嵌入式操作系统与通用操作系统相比，具备以下主要特点：可剪裁性，可移植性，强实时性，强紧凑性，高质量代码，强定制性，标准接口，强稳定性，弱交互性，强确定性，操作简捷、方便，较强的硬件适应性，可固化性。https://shuaici.blog.csdn.net/article/details/140791124【系统架构设计师】二十二、嵌入式系统架构设计理论与实践②-CSDN博客文章浏览阅读469次，点赞8次，收藏13次。中间件 (Middleware)属于可复用软件的范畴。顾名思义，中间件处于操作系统软件与用户的应用软件的中间，在操作系统、网络和数据库之上，应用软件之下，其作用是为处于上层应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。
https://shuaici.blog.csdn.net/article/details/140801697【系统架构设计师】二十一、面向服务架构设计理论与实践①-CSDN博客文章浏览阅读547次，点赞18次，收藏11次。为适应日益增长的用户访问量和产品的快速更新迭代，导致SOA 架构向更细粒度、更通用化程度发展，就成了所谓的微服务了。 SOA 与微服务的区别在于如下几个方面：(1)微服务相比于SOA 更加精细，微服务更多地以独立的进程的方式存在，互相之间并无影响；(2)微服务提供的接口方式更加通用化，例如HTTP RESTful 方式，各种终端都可以调用，无关语言、平台限制；(3)微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。
https://shuaici.blog.csdn.net/article/details/140764750【系统架构设计师】二十、云原生架构设计理论与实践①-CSDN博客文章浏览阅读1k次，点赞17次，收藏22次。云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。云原生的代码通常包括三部分：业务代码、三方软件、处理非功能特性的代码。
https://shuaici.blog.csdn.net/article/details/140695519
