前言
近期因目标客户电脑特殊性(国产处理器加国产系统),而提出调研当下流行的跨平台解决方案,以求判断电脑客户端架构是否有更合适的设计方案。
计划是先根据其业务性质选择软件架构,然后根据需求寻找一些比较合适的技术,最后根据公司实际情况来做取舍。
发布在 CSDN 上仅是为了对于所耗费的时间做一个记录,后续有相关工作能以此为起点提供思路而不必从头开始。
软件架构
架构一词在软件发明时的 N 多年以前,就已经存在了,这个词最早是跟随着建筑出现的。
在软件工程中,架构以理解为 目标系统按某个原则的进行切分。对切分出来的部分,并行或串行开展工作,并对这些部分,设立沟通机制。使得各部分之间能够进行有机的联系,合并组装成为一个整体,完成目标系统的所有工作。
常见的软件架构
分层模式 (Layered pattern)
对结构化设计的软件进行层次上独立的抽象。
适用于 桌面应用程序、WEB应用
表示层(也称为 UI 层)
真实世界的表现层,主要是用户前端。应用层(也称为服务层)
服务层提供商定的协议,可重用性,跨平台的部署。用户做的每一件事都通过表现层和用户界面。业务逻辑层(也称为领域层)
数据访问层(也称为持久化层)
客户端/服务器模式 (Client-server pattern)
由一个服务器与多个客户端构成
适用于 电子邮件应用、文件共享应用、在线业务应用
- 服务器
服务器组件同时为多个客户端组件提供服务。
此外,服务器持续监听来自客户端的请求。- 客户端
客户端向服务器发启服务请求,服务器将相应服务信息回应给客户端。
可以用来编写客户端的技术非常多,不同的语言,不同的排序,简单列举一些我查到的。
主/从模式 (Master-slave pattern)
由主设备与从设备两个部分构成,核心思想是基于分而治之的思想
适用于 数据库集群
- 主服务组件
主服务组件将作业分发给多个从设备组件,并根据这些从设备反馈的结果,计算生成最终结果。- 从设备组件
实际的作业执行者,并将执行结果反馈给主服务组件
管道/过滤器模式 (Pipe-filter pattern)
适用于 生成及处理数据流的系统、编译器
代理模式(Broker pattern)
对结构化系统的组件解耦
适用于 消息中间件软件
对等模式 (Peer-to-peer pattern)
由对等体组件构成,对等体可同时作为客户端与服务端运行
适用于 网络文件共享、流媒体应用
事件总线模式(Event-bus pattern)
应用于事件处理,由四个组件构成
适用于 Android开发、通告服务
- 事件源
- 事件侦听者
- 通道
- 总线
模型/视图/控制器 (MVC) 模式(Model-view-controller pattern)
由三个部分构成,模型、视图、控制器
适用于 互联网网页应用、Django 与 Rails 等网页应用
- 模型
包含核心功能及数据- 视图
呈现信息给用户- 控制器
处理用户的输入操作
黑板模式(Blackboard pattern)
应用未预知的问题确定解决策略,于由三个部分构成,黑板、知识、控制
适用于 语音识别、车辆识别和追踪、蛋白质的结构鉴定、声纳信号解析
- 黑板
用于储存空间对象的结构化全局内存- 知识
源,能自我表意的专用模块- 控制
组件,可将新生成的数据对象写入黑板,也可以通过模式匹配从黑板中获取知识源
解析器模式(Interpreter pattern)
用于设计语言的解析程序
适用于 SQL查询语言,通讯协议扫描语言>
需求
- 电脑客户机本地客户端高适配性
- 调研当前流行的实现方式
当前使用的软件架构及技术搭配
业务层使用 java、服务层使用 thrift、UI层使用 Electron + Vue、数据访问层使用 临时缓存
简单收集的解决方案
- 方案1~用Rust来写业务逻辑,用Neon来做中间连接,用Electron来做UI层
- 方案2~类似于Software+Services的架构,客户端除了GUI什么都没有,全部的应用逻辑都在远端。
方案设计
基于业务场景和需求选择软件架构与技术选型,有很多可选技术不支持跨平台所以并未列举
分层模式
业务逻辑层(也称为领域层)
- 用Java来写业务层。基于JVM机制,跨平台性突出,且生态圈成熟;
- 用golng来写业务层。go语言不具依赖性,不需要使用虚拟机。Go语言的代码可以直接输出为二进制可执行文件,性能优秀,与C/C++、Java同量级,但桌面软件方向应用较少。
应用层(也称为服务层)
- 用thrift写服务层。RPC框架,有人反馈它在0.9.0版本不稳定,目前在现有的项目中都没有暴露过此种问题。支持跨语言,性能比较优秀,相比hessian,高出80%左右;
- 用Hessian写服务层。RPC框架/WebService框架,传输量 < 2M 、并发数未超过 1000 req/s 使用Hessian是够的。支持跨语言,关注度低,上手难度低;
- 用gRPC写服务层。RPC框架,主要面向移动应用开发并基于HTTP/2协议标准而设计,支持众多开发语言,性能低于thrift。
表示层(也称为 UI 层)
- Electron写表现层。支持跨系统,且可以一份代码同时得到网页版和桌面版。开发效率高,执行效率上Electron尽管可以做出与 C++ 应用相媲美的用户体验,例如 Visual Studio Code,但通常难以优化到此地步;
- QT写表现层。C++语言UI框架,支持跨系统,qt还支持移动端,但支持的并不好。发展多年,功能强大,拥有成熟的natvie控件库,但如果用它开发非 GPL 开放程式码(不开放源码)的软体,必須购买商业版本;
- PYQT5写表现层。PyQt对Qt做了封装,可以用PyQt做Qt能做的大部分事情,允许使用Python语言调用Qt库中的API。要注意跨平台方面,如果全部使用QT库问题不大,但如果有用py库,特别是系统API级别的还是会有兼容问题。
数据访问层(也称为持久化层)
- 暂无调研需求
客户端/服务器模式
客户端
- 使用Electron写客户端。用HTML,CSS和JavaScript来构建跨平台桌面应用程序。优点是支持跨系统,开发快,web端与桌面端代码通用。缺点是同标准下没有C++语言的QT高效;
- 使用QT写客户端。优点是有着完整的生态体系,稳定可靠,性能突出。缺点是web端与移动端虽然支持,但生态不完善,相对不够流行。
- 使用JavaFx写客户端。优点是可以跨平台,并且是 Java语言UI框架,缺点是并不流行,生态环境不好;
- 使用Air写客户端。优点是可以跨平台,可以利用Flash做很多动画特效。缺点是开发效率低,随着Flash在浏览器上的节节败退,Air也悄无声息的消失在了大众的视野当中。
- 使用React Native写移动客户端。目前支持iOS和Android两个平台。
- 使用Weex写移动客户端。思想及原理和React Native类似,最大的不同是React Native使用React.js作为开发框架,而Weex则使用Vue.js作为开发框架。也是用来写手机客户端。
服务端
- 暂无调研需求