系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享

系统架构图

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

系统采用四层架构设计

一、展现层

1. Web 前端

基于 HTML/HTML5/Vue/CSS3 开发 web 前端页面,兼容主流浏览器。展现层和数据层完全分离,通过跨域实现前后端数据通信。
2. APP

android,ios 基于原生开发。在 app 端实现 https 链路请求优化,做防盗链和 DNS 劫持处理。
3. 微信公众号 / 微信小程序

更新业务需要,将部分数据以微信公众号 +H5 的方式展现;涉及硬件设备控制功能的系统部分模块采用微信小程序,增加用户操作体验和访问便捷性。
4. Restful 接口

基于特定业务,采用 Restful 标准接口,对外提供数据服务。
二、通讯层

  1. 基于阿里云 CDN 实现静态数据加速;
  2. 基于阿里云 SLB,实现服务器负载均衡;
  3. 基于 TCP/HTTP/HTTPS 三种通信方式,实现前后端数据通信。其中,TCP 基于 Netty 实现;

三、服务层

核心业务基于 Spring Cloud 架构实现微服务化。

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

Spring Cloud 是一个基于 Spring Boot 实现的云应用开发工具,它为基于 JVM 的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

微服务是可以独立部署、水平扩展、独立访问(或者有独立的数据库)的服务单元,springcloud 就是这些微服务的大管家,采用了微服务这种架构之后,项目的数量会非常多,springcloud 做为大管家需要管理好这些微服务。

相关的组件包括如下:

1、Netflix Eureka:

服务中心,云端服务发现,一个基于 REST 的服务,用于定位服务,以实现云端中间层服务发现和故障转移

2、Netflix Hystrix:

熔断器,容错管理工具,旨在通过熔断机制控制服务和第三方库的节点, 从而对延迟和故障提供更强大的容错能力。

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

3、Netflix Zuul:

是在云平台上提供动态路由, 监控, 弹性, 安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门,具有拦截和路由功能。

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

4、Netflix Archaius:

配置管理 API,包含一系列配置管理 API,提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。可以实现动态获取配置,原理是每隔 60s(默认,可配置)从配置源读取一次内容,这样修改了配置文件后不需要重启服务就可以使修改后的内容生效,前提使用 archaius 的 API 来读取。

5、Spring Cloud Config:

俗称的配置中心,配置管理工具包,让你可以把配置放到远程服务器,集中化管理集群配置,目前支持本地存储、Git 以及 Subversion。

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

6、Spring Cloud Bus:

事件、消息总线,用于在集群(例如,配置变化事件)中传播状态变化,可与 Spring Cloud Config 联合实现热部署。

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

7、Spring Cloud Sleuth:

日志收集工具包,封装了 Dapper 和 log-based 追踪以及 Zipkin 和 HTrace 操作,为 SpringCloud 应用实现了一种分布式追踪解决方案。

8、Spring Cloud Task:

主要解决短命微服务的任务管理,任务调度的工作,比如说某些定时任务晚上就跑一次,或者某项数据分析临时就跑几次。

四、数据层

1. mongodb
存储非结构化、关联性弱的业务数据。如,控制器下发的指令数据,监测设备收集的传感器数据,

2. mysql
存储事务性数据,以及关联性将强的数据。如,订单、资金、交易数据;

3. HDSF
存储监控设备上传的图片和视频,以及报表文件;

4. ElasticSearch
实现 ELK,存储日志数据;

其他:

1、认证系统

采用双 token 的方式完成 jwt。其中 accessToken 用于用户身份认证。refreshToken 用于当 accessToken 失效时重新生成。

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

token**** 认证访问(accessToken有效)

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

token**** 认证访问(accessToken失效,refreshToken有效):

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

accessTokenrefreshToken**** 都失效

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

2、日志系统

日志集中化管理,采用 ELK 解决方案。

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

Elasticsearch:是个开源分布式搜索引擎,提供搜集、分析、存储数据三大功能。它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful 风格接口,多数据源,自动搜索负载等。

Logstash :主要是用来日志的搜集、分析、过滤日志的工具,支持大量的数据获取方式。一般工作方式为 c/s 架构,client 端安装在需要收集日志的主机上,server 端负责将收到的各节点日志进行过滤、修改等操作在一并发往 elasticsearch 上去。

Kibana :也是一个开源和免费的工具,Kibana 可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以帮助汇总、分析和搜索重要数据日志。

3、会话治理

此处的会话是指 Netty 会话管理。实现 Channel 自定义会话管理,如会话监控、会话超时、会话重建等。

4、DNS 劫持处理

移动端产品在实际用户环境下会面临 DNS 劫持、耗时波动等问题,这些 DNS 环节的不稳定因素,导致后续网络请求被劫持或是直接失败, 对产品的用户体验产生不好的影响。

DNS 有LocalDNS VS HTTP DNS之分

在长期的实践中,互联网公司发现 LocalDNS 会存在如下几个问题:

  • 域名缓存: 运营商 DNS 缓存域名解析结果,将用户导向网内缓存服务器;
  • 解析转发 & 出口 NAT: 运营商 DNS 转发查询请求或是出口 NAT 导致流量调度策略失效;

为了解决 LocalDNS 的这些问题,业内也催生了 HTTP DNS 的概念,它的基本原理如下:

原本用户进行 DNS 解析是向运营商的 DNS 服务器发起 UDP 报文进行查询,而在 HTTP DNS 下,我们修改为用户带上待查询的域名和本机 IP 地址直接向 HTTP WEB 服务器发起 HTTP 请求,这个 HTTP WEB 将返回域名解析后的 IP 地址。

比如 DNSPod 的实现原理如下:

系统架构设计(通用型),推荐给苦于写文档的同学们,干货分享!

相比 LocalDNS, HTTP DNS 会具备如下优势:

  • 根治域名解析异常: 绕过运营商的 DNS,向具备 DNS 解析功能的 HTTP WEB 服务器发起查询;
  • 调度精准: HTTP DNS 能够直接获取到用户的 IP 地址,从而实现准确导流;
  • 扩展性强: 本身基于 HTTP 协议,可以实现更强大的功能扩展;