2021客户端架构调研过程记录

前言

近期因目标客户电脑特殊性(国产处理器加国产系统),而提出调研当下流行的跨平台解决方案,以求判断电脑客户端架构是否有更合适的设计方案。

计划是先根据其业务性质选择软件架构,然后根据需求寻找一些比较合适的技术,最后根据公司实际情况来做取舍。

发布在 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查询语言,通讯协议扫描语言>


需求

  1. 电脑客户机本地客户端高适配性
  2. 调研当前流行的实现方式

当前使用的软件架构及技术搭配

 业务层使用 java、服务层使用 thrift、UI层使用 Electron + Vue、数据访问层使用 临时缓存

简单收集的解决方案

  • 方案1~用Rust来写业务逻辑,用Neon来做中间连接,用Electron来做UI层
  • 方案2~类似于Software+Services的架构,客户端除了GUI什么都没有,全部的应用逻辑都在远端。

方案设计

基于业务场景和需求选择软件架构与技术选型,有很多可选技术不支持跨平台所以并未列举

分层模式

业务逻辑层(也称为领域层)
  1. 用Java来写业务层。基于JVM机制,跨平台性突出,且生态圈成熟;
  2. 用golng来写业务层。go语言不具依赖性,不需要使用虚拟机。Go语言的代码可以直接输出为二进制可执行文件,性能优秀,与C/C++、Java同量级,但桌面软件方向应用较少。
应用层(也称为服务层)
  1. 用thrift写服务层。RPC框架,有人反馈它在0.9.0版本不稳定,目前在现有的项目中都没有暴露过此种问题。支持跨语言,性能比较优秀,相比hessian,高出80%左右;
  2. 用Hessian写服务层。RPC框架/WebService框架,传输量 < 2M 、并发数未超过 1000 req/s 使用Hessian是够的。支持跨语言,关注度低,上手难度低;
  3. 用gRPC写服务层。RPC框架,主要面向移动应用开发并基于HTTP/2协议标准而设计,支持众多开发语言,性能低于thrift。
表示层(也称为 UI 层)
  1. Electron写表现层。支持跨系统,且可以一份代码同时得到网页版和桌面版。开发效率高,执行效率上Electron尽管可以做出与 C++ 应用相媲美的用户体验,例如 Visual Studio Code,但通常难以优化到此地步;
  2. QT写表现层。C++语言UI框架,支持跨系统,qt还支持移动端,但支持的并不好。发展多年,功能强大,拥有成熟的natvie控件库,但如果用它开发非 GPL 开放程式码(不开放源码)的软体,必須购买商业版本;
  3. PYQT5写表现层。PyQt对Qt做了封装,可以用PyQt做Qt能做的大部分事情,允许使用Python语言调用Qt库中的API。要注意跨平台方面,如果全部使用QT库问题不大,但如果有用py库,特别是系统API级别的还是会有兼容问题。
数据访问层(也称为持久化层)
  • 暂无调研需求

客户端/服务器模式

客户端
  1. 使用Electron写客户端。用HTML,CSS和JavaScript来构建跨平台桌面应用程序。优点是支持跨系统,开发快,web端与桌面端代码通用。缺点是同标准下没有C++语言的QT高效;
  2. 使用QT写客户端。优点是有着完整的生态体系,稳定可靠,性能突出。缺点是web端与移动端虽然支持,但生态不完善,相对不够流行。
  3. 使用JavaFx写客户端。优点是可以跨平台,并且是 Java语言UI框架,缺点是并不流行,生态环境不好;
  4. 使用Air写客户端。优点是可以跨平台,可以利用Flash做很多动画特效。缺点是开发效率低,随着Flash在浏览器上的节节败退,Air也悄无声息的消失在了大众的视野当中。
  5. 使用React Native写移动客户端。目前支持iOS和Android两个平台。
  6. 使用Weex写移动客户端。思想及原理和React Native类似,最大的不同是React Native使用React.js作为开发框架,而Weex则使用Vue.js作为开发框架。也是用来写手机客户端。
服务端
  • 暂无调研需求

你可能感兴趣的:(记录,软件框架)