-
Notifications
You must be signed in to change notification settings - Fork 17
Lark 总体设计
- 背景
- 名词解释
- 设计目标
- 实现的功能
- 设计的性能指标
- 系统环境
- 假设及与其它系统联系
- 相关软件及硬件
- 系统限制
- 数据规模估计
- 设计思路&折衷
- 系统设计
- 基本介绍
- 系统架构图及说明
- 系统流程图及说明
- 与外部系统的接口
- 全局性数据结构说明
- bootstrap 简要说明
- bootstrap的功能
- bootstrap与其它模块的接口
- enrouter 简要说明
- enrouter 的功能
- enrouter 与其它模块的接口
- mvc 简要说明
- mvc 的功能
- mvc 与其它模块的接口
- 基础模块/库简要说明
- 基础模块/库的功能
- 基础模块/库与其它模块的接口
- 基础环境简要说明
- 基础环境的功能
- 基础环境与其它模块的接口
- Lark.js 接入 运维系统平台
- 风险评估&对其他系统的影响
- 已知&可预估的风险
- 与其他系统可能的影响
- 参考资料
Lark 是一个面向大并发大流量互联网服务的工业级Node.js 开发平台,总结了Web, Realtime, Web Push 等业务模式,提供了webserver, MVC分层框架、业务框架、基础库、资源访问层、通用服务等组件,统一业务的逻辑和部署结构,为测试、运维等提供一致的视图。
Lark: 封装了Lark.js框架各模块的包装层模块,目标是使Lark.js框架具有即开即用的功能,用户使用Lark时无需额外编写代码。实现了 ror 的主要功能。 lark-bootstrap: Lark 初始化框架,包含进程管理,载入配置和环境变量等功能 lark-enrouten: Lark router + controller 模块 Lark-MVC: Lark MVC 分层框架 koa: es6 标准的 node.js webserver, 集成在 Lark 里面 yeoman: 生成脚手架的工具 async: 简化异步请求的库
- 高性能。利用node.js的异步非阻塞特性,在大流量高并发时仍然具有低cpu消耗和低内存消耗,设计高并发高流量的服务
- 好架构。参考成熟的架构模式,完成一个完整成熟的node.js架构。同时要保持node.js的细节可控性,对开发者不存在黑盒子
- 最佳实践。集成线上产品的Node.js开发实践,提高Node.js代码的规范性、易读性和执行效率。
- 通用模块。丰富的插件和模块,能满足公司/业界与常用服务交互的需求
- 无依赖。不依赖任何系统环境和库,以方便集成进docker类型的虚拟容器。
- 工业级Node.js架构
- 基础模块/库
- 基础环境
- 与ROR类似的 helper 功能,线上监控,服务部署和实践规范
假设服务类型为webserver, 64G内存12核机器下一个请求需要获取3个后端server的数据,则QPS需要达到 1000+
- Node.js v0.11.14 +
- NPM v2.1.11 +
- yeoman
默认为12核,64G的线上机器
默认不能获得root权限账户,只能获得受限的work账户
10亿级PV
以 webserver 为例, 采用传统的MVC的设计模式:
- 程序启动,进程管理: 读取配置,启动进程,并支持无损重启,debug watch 自动重启等方式。 在 lark-bootstrap 中实现
- Web Server: Web Server 主要处理http请求。本框架采用 koa 库而不是express。采用node.js最新的 es6和generator开发,简化node.js开发难度。
- 路由,Controller 管理: 将路由管理和 controller 合在一处, 简化代码编写复杂度。路由负责把url映射到对应的handler。Controller层负责根据请求的参数执行不同的操作,实现MVC 中的C。
- View层:负责页面展现的工作,在此的任务主要是解析模板。
- Model层:负责对数据的操作,例如读取小说数据、写入阅读记录等。
- dao层: 对数据库读写的封装
- 其它中间件功能模块:采用中间件的流程控制方式,强制将响应请求的动作分割成若干相互独立的部分。在这种模式下,服务器整个响应流程就如同工厂的流水线,而每一个中间件就如同流水线上的一个加工环节。在顶层只需要从宏观控制工作的流程,而在微观则只需要关心当前工作的上下文和自己的职责即可。 对于分层的方式。此系统一共分为5层:router + action层、pageServer层、dataServer层和dao层。每一层的一个类目只会与上下层进行交互,避免各模块间关系的复杂化。
- 每一层都要有自己明确的职责。
- 原则上每一层都只能和自己上一层或者下一层的模块进行交互,这样每层内部各个模块才能保证低耦合度, 避免代码逻辑混乱。 为了尽可能的提高响应速度,应最大化的使用并行处理。
Lark 针对不同的业务类型设计了不同的架构。这里以 webserver 为例:
以线上服务为例,整体的架构图如下:
(待补充图片)
其中 lark.js 框架的流程图如下:
(待补充图片)
- Web Server: Web Server 主要处理http请求。本框架采用 koa 库而不是express。采用node.js最新的 es6和generator开发,简化node.js开发难度。
- 业务层主要分为5层:
- router层 + action:对url进行解析,参数处理,并分发到对应的controller层模块进行处理。支持根据文件路径解析url, 每一个文件对应一个url的path
- pageServer层:根据调用方的请求,向不同的data层模块请求需要的数据,或者执行相应的动作。一般来说,每一个pageServer层对应一个页面的数据。因此一般来说,一个action层模块对应一个page层模块。
- dataServer层:数据层,负责提供一个数据实体模型对应的数据,例如小说的基本信息(包括书名、作者等)、目录、离线小说数据等。
- dao层:负责与后端交互。一般来说一个dao层模型对应一种类型的后端,或者一张数据库的表。
- 其它功能通过中间件的形式插入服务中
在router层和pageServer层,主要执行业务相关的逻辑,无须关心数据方面的具体操作。 而在dataServer层和dao层,则主要执行数据相关的逻辑,无需关心业务方面的逻辑。
(待补充图片)
lark.js的其它优点:
- 无依赖,更适合 docker 等容器扩容
- 异步非阻塞模型,适合高并发大流量的服务
- 类似于 ROR 的 helper
系统前端可以为Nginx/Lighttp等反向代理服务器,方向代理服务器直接给系统倒流。 后端可以为服务化的数据,检索等模块,通过restful 或 protobuf rpc等方式交互 管理进程等可以通过pm2暴露的接口进行管理 MVC, router 等可以通过配置自定义
该模块负责程序启动,进程管理
- 程序启动,并且supervise 进程,挂了自动重启
- 进程管理,通过pm2 查看进程状态
- 配置读取
通过传递配置进行通信
该模块负责路由以及 部分 controller 功能
- 路由,将请求映射到相应的handler
- controller,根据用户不同的请求参数调用不同的后端模块,返回结果
通过传递配置进行通信
实现 web server 的 mvc 功能
-
模块加载: 该功能主要用于模块的加载,默认会按照 Lark 制定的 MVC 规范去相应的目录加载模块。 eg: var mvc = require('lark-mvc'); //会去指定的 model 目录中require。
-
MVC 封装: 主要用于 MVC 设计模式的通用逻辑封装。提供通用的 MVC 方法。 eg: this.dataServices.demo.getData();
通过传递配置进行交互 目前支持 path 参数,能修改 mvc 业务代码存放的位置
基础模块主要用于提供通用的业务逻辑,他们应该独立于 Lark ,可以单独运行。
目前的基础模块 conf:用于配置文件的加载、解析、获取、修改等 log:用于日志的生成 pm:用于进程监控 库: redis mongodb
调用后端数据库或者已有的服务API接口
通过参数交互
可以用pm2 deploy 上线
支持启停方式 lark start|stop|restart
按系统指定的方式进行idc配置
日志默认放/app-path/log 下
pm2 提供监控功能
-
已知&可预估的风险
- 日均流量比较高,因此有因数据端不可用而出现雪崩的风险。
- 服务端连接的前端和数据端数量均比较多,容易出现沟通不畅的情况,进而引起一系列问题。
-
与其他系统可能的影响
- 可能引起下游服务的异常。
- 如果是Restful API接口,当服务出现异常时,会引起调用这些服务的其它服务也出现异常。