MaWenge's Blog

软件分层设计思想

什么是分层

我所理解的分层,是对 实现某个功能的过程 进行分层。实现功能的过程是由 很多服务有序组合完成,把相似的服务放在一层当中,把不相似的服务分开,简而言之,就是 对服务进行分层

分层的应用

分层的思想在各个领域可以说是随处可以看到

房屋建设

我认为可以分为这几层

这里的实现的 功能 就是 建好房子并且卖出去。 我把中间涉及到的服务简单的分成了三层。最上层是地产商经营服务,主要负责房屋销售、融资筹钱等服务;第二层是建筑承包服务,主要负责房屋的建设服务,它接受地产商的指示,最终提供给地产商符合要求的产品;第三层是原料供应商,它负责接受建筑承包商的指示,提供给建筑承包商符合要求的产品。
都是上层向下层索要特定需求的产品,下层根据需求提供给上层符合条件的产品,双方都不需要知道对方的实现细节。

网络传输模型

数据在一个网络中的两台机器之间传输,可以说数据就是在这些层当中不断的流动,最终达到了传输数据的目的。

首先,每一层实现的功能不同
应用层:OSI参考模型中最靠近用户的一层,是为计算机用户提供应用接口,也为用户直接提供各种网络服务。
表示层:应用层数据的编码和转换功能。用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。
会话层:会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。
传输层:传输层建立了主机端到端的链接,传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务,包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节,使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的,TCP UDP就是在这一层。端口号既是这里的“端”。
网络层:本层通过IP寻址来建立两个节点之间的连接,为源端的运输层送来的分组,选择合适的路由和交换节点,正确无误地按照地址传送给目的端的运输层。就是通常说的IP层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。
数据链路层:将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。
物理层:实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。

其次,实现每一层功能的对象是不同的

其中应用层(会话层、表示层、应用层)大多通过软件实现其功能。可以说每一层都有专业的对象负责实现本层的功能。

再其次,每一层遵守的协议也不同

每一层的工作都很明确,从上层接收数据(对于应用层直接传递给下层),根据协议处理或者传输数据,再把数据传递给下一层(对于物理层从上层接收数据传递后继续传递给上层)。每一层只负责依据协议读取数据,处理数据,传递数据。不需要了解上层或者下层的实现细节。如此只要每一层都做好自己的事情,最终就能达到数据传输的目的。
这里实现的功能就是完成数据传输,每一层都提供了服务,最终合起来就共同实现了功能。

安卓平台架构

安卓操作系统其实也是典型的分层架构

Linux内核:Android 平台的基础是 Linux 内核。例如,Android Runtime (ART) 依靠 Linux 内核来执行底层功能,例如线程和低层内存管理。
使用 Linux 内核可让 Android 利用主要安全功能,并且允许设备制造商为著名的内核开发硬件驱动程序。
硬件抽象层:硬件抽象层 (HAL) 提供标准界面,向更高级别的 Java API 框架显示设备硬件功能。HAL 包含多个库模块,其中每个模块都为特定类型的硬件组件实现一个界面,例如相机或蓝牙模块。当框架 API 要求访问设备硬件时,Android 系统将为该硬件组件加载库模块。
Android Runtime:对于运行 Android 5.0(API 级别 21)或更高版本的设备,每个应用都在其自己的进程中运行,并且有其自己的 Android Runtime (ART) 实例。ART 编写
原生 C/C++ 库:许多核心 Android 系统组件和服务(例如 ART 和 HAL)构建自原生代码,需要以 C 和 C++ 编写的原生库。Android 平台提供 Java 框架 API 以向应用显示其中部分原生库的功能。例如,您可以通过 Android 框架的 Java OpenGL API 访问 OpenGL ES,以支持在应用中绘制和操作 2D 和 3D 图形。
Java API 框架:您可通过以 Java 语言编写的 API 使用 Android OS 的整个功能集。这些 API 形成创建 Android 应用所需的构建块,它们可简化核心模块化系统组件和服务的重复使用。
系统应用:Android 随附一套用于电子邮件、短信、日历、互联网浏览和联系人等的核心应用。平台随附的应用与用户可以选择安装的应用一样,没有特殊状态。因此第三方应用可成为用户的默认网络浏览器、短信 Messenger 甚至默认键盘(有一些例外,例如系统的“设置”应用)。虽说官方把系统应用单独设置成一层,但是我们使用的各种app实际上应该是跟这些系统应用在同一层的位置,主要调用下一层的Java api框架。

其实其他操作系统(windows Linux)也是有明确的分层,绝大多数开发者编写的代码都是明确的在各自的层中运行,调用其它层或者给其它层调用

后端服务架构

这里介绍一下目前我自己后端服务的分层架构,也是参考了网络上一些通用的架构方案,没有什么技术含量。

database layer:数据库服务,用的是阿里云的rds,基本上就是配置一下就行了。
persistence layer:持久层,用于与数据库直接交互,主要就是增删改查,我用的是mybatis,其实也叫dao层,主要包括定义好的一些mapper的xml文件和接口文件。这里可以把功能抽象在接口里面,用以适配不同的数据库服务。
service layer:服务层,这部分应该是对持久层做了一些原子性更大一些的组合。我个人认为这一部分的思想可以跟关系型数据库的存储过程很相似。
business layer:业务层,这里涉及到的就是具体的业务了。比如现在的项目是共享电瓶车租赁。相关的业务就会有租还车,车辆管理等等。业务层可以直接调用持久层,也可以调用服务层。
presentation layer:展示层,负责处理所有的界面展示以及交互逻辑。目前的业务主要就是对移动端请求的处理,现在主要就是各种controller,后台静态页面部署在另一台机器上。

其他一些权限过滤、异常处理等这里暂时先不考虑。

spring框架下的这种架构实现起来也非常容易,代码看起来也很清爽,维护起来也没有什么很大的问题。

总结

不难发现,分层的思想在生活当中随处可见,分层真的就是一种正确实用的方案吗?这个也是要根据需求以及实际情况衡量。这里我们只讨论分层特点。

1 分层易于实现分工,每一层人员负责的不同,只需要专注自己的业务即可。
2 分层易于实现代码复用,这也是分层出现的一个直接原因。
3 分层易于测试。由于实现了分层,功能粒度理论上是可以做到很细,单元测试用例编写也会非常灵活。

参考
软件架构模式之分层架构
针对架构设计的几个痛点,我总结出的架构原则和模式
OSI七层模型与TCP/IP五层模型