一起网开发平台结构附带图片

最新推荐文章于 2023-06-14 17:28:07 发布

蓝冰大侠

最新推荐文章于 2023-06-14 17:28:07 发布

阅读量615

点赞数

分类专栏：编程语言

本文链接：https://blog.csdn.net/bluehire/article/details/17499047

版权

编程语言专栏收录该内容

179 篇文章 1 订阅

订阅专栏

一、绪论1) 引言由于本人对一起网系统的掌握程度有限，仅根据以往项目经验及个人当前对一起网系统的粗浅了解，提出一些对开发平台的构想，以起到抛砖引玉的作用。
2) 适用范围随着一起网用户的增长以及其他 SNS

类网站的发展，一起网平台需要达到一个新的高度以迎接更多的挑战。包括大用户情况下的运行效率，自有应用及开放应用的大量增长，随时变化的功能需求及界面需求等。
本文仅根据一起网当前存在的问题及近期可能遇到的问题进行探讨，以期提出一个可以在一定时间内满足用户及公司要求的系统平台。
3)  目标提高开发效率；
减少程序错误；
产品便于维护；
产品便于扩展；
降低开发与运营成本；
可接受的运行效率。
4)  原则１．代码分离。
a)          MVC 分离；
b)          布局与样式分离；
c)          业务逻辑与数据访问分离；
d)          应用与平台分离；
e)          平台与框架分离。
２．明确层次关系及接口。
a)          各个层之间实现偏序关系，即高层代码可以访问低层功能及同层次功能，但低层代码不可以访问高层功能；
b)          每个模块不仅要明确输出接口 ( 即本模块所提供的功能 ) ，同时也要明确输入接口 ( 使用到了哪些模块的功能 ) 。
３．松散耦合。
a)          层次之间及模块之间的接口尽可能少 , 每个模块尽可能独立完成自己的功能 .
４．代码重用。
a)          多次重复使用的代码应单独提出作为模块 / 方法 / 函数。
５．硬件分布。
a)          相对独立的模块分布在不同的服务器上，相互之间通过网络交换数据。
６．职能细化。
a)          系统划分尽可能详细，对需要同类专业技能的模块进行归类，降低对开发人员的技能要求。
5)  作用 1．    缩小每个模块的规模；
2．    降低系统复杂度；
3．    阻断错误的传播；错误被最大可能限制在模块内部；
4．    任一模块都可以独立升级 , 更换；
5．    模块化之后 , 单元测试成为可能；
6．    提高运行效率 . 各个模块可以分布部署；
7．    提高可靠性 . 可以有针对性地对部分模块进行镜像，双机备份，负载均衡；
8．    减少用户首次响应时间；
9．    减轻中央服务器负担；
10． . 每个开发人员可以专注于一个较小范围的技术技能；并在此领域内达到较高的技术水平；极大提升此领域代码开发效率与代码质量；
11．精通所有技术领域的技术人员是不存在的；同时精通多个领域的技能人员是稀少的；但仅精通一到二个领域的技能人员很普遍；
12．降低开发人员学习成本与培训成本；由于只关注较少的技术技能；新加入团队的开发人员可以在短期内掌握该领域的知识与技能 , 及时形成战斗力；
13．人事考量。此方面不在技术讨论群组中论述。
二、     系统分布1)  总体分布2)

内网分布

三、     模块功能1)  自有应用模块 (1)        本模块中包括 WEB 服务器与数据库服务器
(2)        本模块完成自有应用的应用区表现功能
(3)        使用数据访问层访问自用数据库
(4)        访问平台数据服务模块获取其它模块数据
2)  自有应用数据服务模块 (1)        本模块中包括 WEB 服务器与数据库服务器
(2)        本模块为其它模块提供数据 , 由平台数据服务模块通过 HTTP 调用
(3)        使用数据访问层访问自用数据库
3)  场景应用模块 (1)        本模块中包括 WEB 服务器与数据库服务器
(2)        本模块完成场景应用的非应用区表现功能
(3)        使用数据访问层访问自用数据库
(4)        访问平台数据服务模块以获取其它模块数据
4)  场景应用数据服务模块 (1)        本模块中包括 WEB 服务器与数据库服务器
(2)        本模块为其它模块提供数据 , 由平台数据服务模块通过 HTTP 调用
(3)        使用数据访问层访问自用数据库
5)  平台数据服务模块 (1)        本模块中包括 WEB 服务器 , 但不包括数据库服务器
(2)        本模块以 HTTP 调用方式为其它模块提供数据 ,
(3)        本模块通过 HTTP 调用方式访问自有应用数据服务模块及场景应用数据服务模块获取数据
6)  平台模块 (1)        本模块中包括 WEB 服务器 , 但不包括数据库服务器
(2)        本模块为用户提供页面表现功能
(3)        本模块为用户页面提供布局模板
(4)        访问开放应用 , 获取页面模块并渲染
四、     文件组织结构每个模块的文件按以下目录组织，部分模块可以缺少一项或若干项
                   C       控制器
M     业务逻辑类
                   V       视图
1.          cont_x               指定控制器的模板文件 , 子目录中存放本控制器使用的资源文件
a)          js                 静态 JS 脚本文件
b)          css             静态 CSS 样式文件
c)          img             静态布局图片文件
d)          swf             静态动画文件
e)          html           静态页面布局文件
f)            data           静态数据文件
g)          language 多语言（暂不实现）
                                                                   i.                zh
                                                                 ii.                en
2.          public                           多个控制器共用的资源文件
a)          js
b)          css
c)          img
d)          swf
e)          html
f)            language
                                                                   i.                zh
                                                                 ii.                en
                   Api                               对外接口
                   Config                         配置文件
                   Exception                             异常
                   Log                               文本日志
                   Lib                                 第三方库
                   Framework                 框架文件
Temp                           临时目录
五、     模块设计要点1)  框架 (1)        为平台与应用开发提供一个统一的基础框架
(2)        较短时间内可完成基本功能
(3)        可在平台与应用开发过程中按需扩展
(4)        提供配置文件管理，多语言，缓存，日志， mvc 控制，数据访问模块， smarty 模板， js 库等基础功能
2)  平台 (1)        包括平台模块与平台数据服务模块
(2)        作为中央服务器，集中协调各个应用模块的功能，为用户访问输出布局
(3)        可以访问公用数据库
(4)        渲染开放应用模板
3)  应用 (1)        包括应用模块与应用数据服务模块
(2)        使用自有数据库中的数据
(3)        可访问平台数据服务模块获取其它应用的数据及公用数据
4)  数据访问层 (1)        对数据库访问进行简单封装 , 以运行效率为主 , 兼顾可维护性
(2)        数据访问层中集成 memcache ，以提供透明的数据缓存服务
(3)        使用 PDO 数据访问接口
5)  功能前移，负载前移 (1)        单独为 SEO 准备 RSS, 所有页面不考虑 SEO, 不考虑静态化 , 不考虑 URL 重写
(2)        所有应用中尽可能使用 Ajax 无刷新更新，延迟读入，前端组装
(3)        C 扩展模块逐渐使用 php 替代
6)  Js框架的选用 (1)        相比 prototype, JQuery 提供了更强大的选择器，结构清晰简单。
7)  页面分块装载 (1)        平台模块提供页面布局
(2)        浏览器通过 Ajax, 延迟装载页面片段 , 前端组装
(3)        自有应用模块提供应用区页面片段
(4)        场景应用模块提供非应用区页面片段
(5)        每块独立 http 请求，延迟装载，充分利用浏览器缓存及 WEB 服务器缓存，同时改善用户体验；系统层次扁平化。便于分布。降低系统复杂度。
8)  充分oop (1)        尽可能用类来实现各种功能，减少过程化代码，尤其是全局代码，全局变量，全局常量，全局函数
(2)        try/catch 　异常处理
(3)        可以对类进行单元测试
9)  静态文件 (1)        js 与 css 不必独立，浏览器与 web 服务器都可以有效缓存，布局中的图片也不必要独立。在 web 服务器压力增大时，可以采用静态文件缓存技术来解决
10) session共享 (1)        可以使用 memcache 共享
11) 多语言与本地化 (1)        按一起网现在的发展阶段 , 不建议进行多语言化与本地化 . 多语言化与本地化将极大降低代码的可读性 , 增加维护难度 . 可以在一起网的中文版本发展到一个比较稳定的阶段后再考虑 .
12) infoDB (1)        转换为 MYSQL
13) 后台管理 (1)        暂不考虑
14) AC (1)        暂不考虑
15) 日志 (1)        需要讨论 , 本地文件 / 网络文件 / 数据库
六、     开发顺序