关于新版一起网平台的一些想法

忘是亡心i 2022-09-19 10:44 217阅读 0赞

由于本人对一起网系统的了解程度有限，仅对系统结构有所初步掌握，至于细节部分可以说是一无所知。  
现阶段并不能提出一个完整的平台设计或构想，仅仅提出一些杂乱的想法以供大家参考。  
目标：  
平台架构要为以下目标服务:  
１．提高开发效率  
２．减少BUG  
３．产品便于维护  
４．便于扩展  
５．大量用户访问时仍能较快提供服务  
  
为实现以上目标,通常采取以下方法  
１．代码分离。MVC分离,布局与样式分离,业务逻辑与数据访问分离，应用与平台分离，平台与框架分离等.  
２．明确层次关系及接口。各个层之间实现偏序关系,即高层代码可以访问低层功能及同层次功能,但低层代码不可以访问高层功能;每个模块不仅要明确输出接口(即本模块所提供的功能),同时也要明确输入接口(使用到了哪些模块的功能)  
３．松散耦合。层次之间及模块之间的接口尽可能少,每个模块尽可能独立完成自己的功能.  
４．代码重用。多次重复使用的代码应单独提出作为模块/方法/函数.  
５．硬件分布。相对独立的模块分布在不同的服务器上，相互之间通过网络交换数据。  
  
这些方法可以带来以下好处  
1.代码分离  
a.开发人员职能细化.每个开发人员可以专注于一个较小范围的技术技能,并在此领域内达到较高的技术水平,极大提升此领域代码开发效率与代码质量.  
b.降低对开发人员的技能要求.精通所有技术领域的技术人员是不存在的.同时精通多个领域的技能人员是昂贵的.但仅精通一到二个领域的技能人员很普遍.  
c.降低开发人员学习成本与培训成本.由于只关注较少的技术技能,新加入团队的开发人员可以在短期内掌握该领域的知识与技能,及时形成战斗力.  
d.人事考量,此方面不在技术讨论群组中详述  
2.明确层次与接口  
a.提高产品的可扩展性及可维护性.任一模块都可以独立升级,更换.  
b.减少BUG.模块化之后,单元测试成为可能.  
3.松散耦合  
a.减少BUG.错误被最大可能地控制在模块内部  
b.提高运行效率.各个模块可以分布部署  
c.提高可靠性.可以有针对性地对部分模块进行镜像或备份  
4.代码重用  
a.提高开发效率.  
b.减少及控制错误  
c.可维护性,可扩展性  
5.硬件分布  
a.减轻中央服务器负担  
b.每一部分可采用双机备份以提高可靠性  
c.每一部分可采用负载均衡以满足用户增长  
  
系统分布(过度设计)  
  
开放应用（包括F8,OS）  
１． 每一个开放应用都是一个独立服务器，与平台进行网络通讯  
２． 有自己的数据库  
３． 访问平台应用接口，以获取数据  
a) 获取自有应用数据  
b) 获取场景应用数据  
４． 被平台所访问，返回开放应用模板，  
a) 经平台渲染后使用  
自有应用（日志，叽歪，。。。）  
１． 每一个自有应用都是一个独立服务器，与平台进行网络通讯  
２． 有自己的数据库  
３． 访问平台应用接口，以获取数据  
a) 获取其它自有应用数据  
b) 获取场景应用数据  
４． 被平台所访问，返回自有应用页面  
５． 被平台所访问，返回自有应用数据  
场景应用（我家，群组，。。。）  
１． 每一个场景应用都是一个独立服务器，与平台进行网络通讯  
２． 访问共同的数据库  
３． 访问平台应用接口，以获取数据  
a) 获取自有应用数据  
４． 被平台所访问，返回场景页面块  
５． 被平台所访问，返回场景应用数据  
平台  
１． 对外提供接口，输出数据  
a) 为开放应用服务  
i. 输出自有应用数据  
ii. 输出场景应用数据  
b) 为自有应用及场景应用服务  
i. 输出自有应用数据  
ii. 输出场景应用数据  
２． 对外提供接口，输出页面  
a) 为用户服务  
i. 输出场景应用页面与应用页面的组合  
３． 访问应用，输入数据  
a) 访问自有应用，获取自有应用数据  
b) 访问场景应用，获取场景应用数据  
４． 访问应用，输入页面  
a) 访问开放应用，获取开放应用模板，并渲染  
b) 访问自有应用，获取自有应用页面  
c) 访问场景应用，获取场景应用页面  
１． 体系结构  
框架层：  
提供配置文件管理，多语言，缓存，日志，mvc控制，数据访问模块，smarty模板，js库等基础功能  
为平台层与应用层开发提供一个统一的基础框架  
短时间内即可完成  
可在平台层与应用层开发过程中按需扩展  
平台层：  
提供与应用的接口（输入与输出）  
提供与用户的web接口，包括ajax  
可访问场景数据库  
需要对接口进行详细设计  
可在应用层开发过程按需扩展  
应用层：  
每个应用可分布开发  
２． 数据访问层缓存  
数据访问层中集成memcache，以提供透明的缓存服务  
３． 部分功能向前端迁移  
除需要seo的场景外，其它场景中尽可能使用Ajax无刷新更新，延迟读入，前端组装  
扩展模块逐渐使用php替代  
４． Js框架的选用  
相比prototype,Jquery提供了更强大的选择器，结构清晰简单。  
５． 页面分块装载  
每块独立http请求，延迟装载，充分利用浏览器缓存及ＷＥＢ服务器缓存，同时改善用户体验；系统层次扁平化。便于分布。降低系统复杂度。  
６． 充分oop  
a) 尽可能用类来实现各种功能，减少过程化代码，尤其是全局代码，全局变量，全局常量，全局函数  
b) try/catch　 异常处理  
７． js与css不必独立，浏览器与web服务器都可以有效缓存，布局中的图片也不必要独立。在web服务器压力增大时，可以采用静态文件缓存技术来解决  
8.应用与平台分离，导致session共享问题，可以使用memcache共享  
  
文件结构（应用与平台分别部署）  
C  
M  
V  
Api  
Config  
Exception  
Log  
Lib  
Framework  
Temp  
文件结构（应用与平台部署在一起）  
１． appication自有应用及场景应用  
a) app\_x　  
i. c  控制器  
ii. m  业务逻辑类  
iii. v  视图，每个控制器对应一个目录  
1. cont\_x  指定控制器的模板文件,子目录中存放本控制器使用的资源文件  
a) js  
b) 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  
iv. api    提供服务接口  
v. config   所有配置文件  
vi. exception   所有异常类  
vii. log    本地文件日志  
２． lib  
a) smarty  
３． framework  框架文件  
４． Temp   临时文件夹，可能放置上传的文件  
a) template\_c  Smarty的编译文件  
５． Platform 平台  
a) Api 提供服务接口  
b) C  
c) M  
d) V  
e) Exception  
f) Log  
g) Config

阅读(121) | 评论(0) | 转发(0) |

上一篇：一起网PHP编码规范（征求意见稿）

下一篇：PHP 获取MSN好友列表 组信息 发送离线消息 (一)