ecos技术白皮书文档格式.docx
- 文档编号:22471362
- 上传时间:2023-02-04
- 格式:DOCX
- 页数:19
- 大小:450.19KB
ecos技术白皮书文档格式.docx
《ecos技术白皮书文档格式.docx》由会员分享,可在线阅读,更多相关《ecos技术白皮书文档格式.docx(19页珍藏版)》请在冰豆网上搜索。
1.业务在高速的发展过程中,需要不断地根据市场情况进行调整,对系统变更的响应及时性要求很高;
2.希望自己的信息系统能较好进行整合,系统间配合良好,同时能快速的接入各大集市型交易平台,如淘宝等;
3.希望降低自己的开发成本,同时吸取业内的成功经验;
4.希望信息化统一规划,实现统一业务架构和开发平台;
5.希望随着业务的发展,系统具备扩展的能力;
基础架构
ECOS是Rails风格的PHP快速开发框架,EC意味着电子商务,OS意味着操作系统,操作平台。
它是一个完全由APP组成的系统,每个APP采用统一的约定组装在一起。
如果说ECOS像linux一样由许多包组成,那么base包就是ECOS的内核(kernel)。
在base中封装了大部分的性能敏感资源访问,使得构建于其上的其他应用不需要考虑后端的资源实现。
ECOS架构图
这使得具体应用不需要考虑后端实现,而ECOS的整体性能会随着部署环境的提升而提升。
与linuxKernel不同的是:
BASE提供了软件包管理机制。
BASE让软件包的安装和卸载非常便捷,只要一个命令,就可以像Yum/Apt一样为ECOS安装新的功能包。
ECOS上的应用可以创建自己的数据表,创建自己的业务规则,操作视图。
更强大的是应用间的协同扩展能力。
OSGI是JAVA下的一个组件化设计,其代表产品是编辑器Eclipse,该工具生命力非常强大,可以通过组件来扩充使其适合软件开发工艺中的各个流程。
ECOS尝试作为一个类似OSGI的简易实现,简化其开发成本,而由不失去其灵活性。
随着商派基于ECOS的产品线发展,新的应用可以灵活的扩展原有应用的界面和流程,证明该尝试是非常成功的。
OSGI的部署单位是Bundle,对应在ECOS中就是APP。
其共性是具有称为“服务”的扩展接口。
通过Service机制,App之间可以扩展功能,界面,和操作流程。
而不必担心原有应用升级带来的问题。
ECOS是全消息驱动设计,采用事件机制,可以通过少量开发即可连接企业数据总线ESB,与您的企业原有信息系统更紧密集成,让您之前的IT投资得到增值。
采用ECOS可以提高二次开发效率,建表、建数据模型、建控制器只需进行简单定义即可完成。
ECOS拥有的具备浓厚Rails风格的代码架构,可以像脚手架一样帮助研发团队节省大量编码时间,从而使团队更关注于业务,而不必关注代码细节。
同时,ECOS是商派开发经验的体现,上海商派在历时八年软件开发过程中的体悟,开发流程的管理经验,敏捷开发思想都浓缩在ECOS的开发工具中。
自带TDD和持续集成工具,协助您的技术团队规范开发流程。
技术特性
1.业务与底层实现技术分离,增加灵活性
ECOS通过对业务的抽象,使其与实现该业务的具体系统实现技术相分离,从而达到业务的技术无关性。
通过该项技术,可以实现在应用架构上的随需应变。
随着用户规模的扩展,对ECOS架构的信息系统高性能、高可用的要求越来越高,当需要对底层支持技术进行变更时,业务部分代码无需进行任何变更,只需编写底层实现或选用ECOS预置的大量底层实现技术,完成零成本或极低成本进行底层实现技术的跃迁。
而在传统的编码方式中业务与底层实现技术往往代码是混在一起的,此时对于底层实现技术的变更,需要对所有相关代码进行重写,成本非常高。
如上图所示,图片的存储对于不同发展阶段的网站来说,有不同的解决方案:
本地文件系统存储、远程文件系统存储、KVStore存储、公共存储服务(如AmazonS3)等。
当网站处于初期阶段时,完全可以采用本地文件系统存储方式,随着网站访问量的增大,我们需要采用集群解决方案,此时我们需要更换存储策略为远程文件系统存储,而后,系统中的图片量不断增大,文件系统不堪重负,此时我们又需要变更为KVStore存储或公共存储服务方案,在ECOS架构下,这些变更除了迁移成本,其它人力成本几乎为零,而这在传统编码方式下是不可想像的。
2.强大的业务集成能力,消除信息孤岛
ECOS平台提供了前所未有的业务集成能力,从电子商务企业整体出发,统一了组织机构、业务分工、业务权限、基础资源的管理,将各类业务构建成统一的、集成的系统,满足电子商务业务的全面管理。
以往企业在信息化的过程中积累了大量的独立应用系统,他们一般以项目为主,也有部分是企业自主开发,往往使用了多种开发技术,多种数据存储结构。
导致了各系统之前都是独立存在的,信息和流程也是封闭的,但是真实的业务场景是企业里的各种业务和岗位是互相联系的,这样导致了岗位部门间的重复冗余的工作,使得企业的工作效率大大降低,运营成功不断提高。
为了解决业务集成的问题,很多系统提出了自己的集成解决方案,但是大都是各自为阵,为解决当前问题而设计了很多复杂的“接口”,时间长了造成企业整个业务系统之间关系错综复杂,极难维护,最终导致系统的全部重构。
这样给企业的发展造成了很大伤害。
于是,面向服务的体系结构(Service-OrientedArchitecture,SOA)诞生了,SOA把各个独立系统间,那么这个信息的中间交互层,通常被称为企业服务总线(EnterpriseServiceBus,ESB)。
各个系统通过向ESB发送一致的信息保证各节点的信息交互,老的项目只要建立一个连接esb的中间件(Adapter)即可完成和其他所有系统的通信,而不必一一连接。
ECOS在一开始就将多系统联通,保护用户现有投资作为设计重点,从外部接口上保证自身是符合SOA特性的开放性服务提供者和消费者。
另外,对于ECOS来说,SOA有两个层次的体现:
第一在和外部系统
的生态环境中,作为SOA的一个服务提供者,和服务消费者的身份而存在。
可以联通到企业自身的ESB(企业服务总线)上。
第二ECOS是一个完全以应用包的形式组成的系统,各应用之间通过SOA风格的接口进行通信。
ECOS本质上是一个服务整合运作环境,类似java体系的osgi。
各应用之间可以随时动态增删扩展。
商品保存时,不需要知道图片具体是存在文件系统还是ftp中,具体的保存细节由专门的软件包提供服务,而且又可以随意扩展提供该服务的软件包。
3.前后端特性支持兼备,降低企业运营成本
在谈及电子商务应用的时候,通常会谈前端,后端两个部分。
前端是指在线业务的可见的部分比如B2C的购物界面,B2B的批发网站。
电子商务的后端是指在支撑前端响应的整个管理系统,负责信息流,物流,金流的管理。
其特点是多变,电子商务业务发展有多快,业务的变化就有多快。
一个月前5个分拣发货人员可能可以满足要求,但一个月后订单量可能就有数量级的提升。
随着业务的变化,企业的管理方式也要迅速发生变化,因此电子商务系统对后端的要求就是相应变化,适应现代电子商务企业速度。
传统的企业管理软件可能就无法快速相应满足要求,此时PHP的QuickANDDirty优势就渐渐显现出来。
ECOS为电商而生,就必须同时满足以上两种场景。
ECOS为前端有精心设计的缓存体系以及集群化的部署都有底层上的支持,使得处理大并发,高负载得心应手。
采用了全APP化,通过SERVICE的设计来强化后端系统扩展性,通过良好的MVC抽象去掉QuickandDirty中的Dirty部分。
使得一个框架可以同时满足前后端两种应用场景。
各业务端都采用统一技术体系,有利于降低企业维护成本,降低风险,方便培训和人力资源储备。
4.安全性
ECOS使用BASE作为所有资源的抽象管理,通过Object-ResourceMap的设计,使得程序员很少有机会直接操作低层资源,所有的资源都使用BASE接管,即保证了安全性,又提高了性能和兼容性。
ECOS在所有前端输出的地方针对资源都做了谨慎处理,保证所有资源都在一个HTTP访问模式下,使得HTTPS兼容良好,采用https模式对于tcp嗅探和劫持有很好的防御作用。
ECOS对于所有的认证独立的应用PAM完成,该应用会统一记录所有身份认证信息。
为系统安全审计提供支持。
认证和授权是分开设计,授权由DESKTOP后台统一操作界面完成,其权限的管理采用经典的基于角色的访问控制(Role-BasedAccessControl)
RBAC认为权限授权实际上是Who、What、How的问题。
在RBAC模型中,who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。
Who:
权限的拥用者或主体(如User、Group、Role、Actor等等)
What:
权限针对的对象或资源(Resource、Class)。
How:
具体的权限(Privilege,正向授权与负向授权)。
Operator:
操作。
表明对What的How操作。
也就是Privilege+Resource
Role:
角色,一定数量的权限的集合。
权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系。
Group:
用户组,权限分配的单位与载体。
权限不考虑分配给特定的用户而给组。
组可以包括组(以实现权限的继承),也可以包含用户,组内用户继承组的权限。
User与Group是多对多的关系。
Group可以层次化,以满足不同层级权限控制的要求。
5.可扩展性
ECOS是基于OSGI模型的开放开发框架,所有业务需求都可以转化成一个相对独立较小的APP动态的集成到整个ECSTORE中,使得整个业务系统随需而建,随需而扩。
业务横向扩展性
每个独立的APP有自己独立的安装、配置、依赖、服务等管理。
可以在其基础上开发任意业务模型的应用。
业务纵向扩展性
在APP之内通过建立SERVICE,使其他的APP可以能够对建立相应SERVICE的APP进行纵向的扩展
部署扩展能力
在ECOS底层为集群化部署留有相应的接口和配置文件,能够从容的对系统进集群化部署
ECOS框架本身可扩展
ECOS底层由微内核、基本MVC框架、工具集等一套基础APP组成,可以随需定制升级内核完成复杂功能的定制,实现无限扩展可能性。
6.可维护性
会进化的系统才拥有最强的生命力
系统在正式运行之后,长期可维护性尤为重要。
系统在运行多年之后,新功能调整就像补丁打补丁一样,周期越来越长,成本越来越高。
所以一个经过长期设计的系统尤为重要。
ECOS在设计过程中参照了很多成熟的架构体系。
最重要的是,ECOS是全组件化的。
并且,在这个组件化体系里没有所谓的超级应用。
就像linux一样,经典的sed,aw,grep仍然有效。
应用层的战争也会长期存在,今天你用apache,明天可能就换成了lighttpd,后天可能又变成nginx。
不变的是整个生态环境和他们所提供的同样服务:
http。
第一,ecos创建的是一个生态圈,给了在这个生态圈下动态竞争发展的机制。
第二,ECOS设计了一个底线,就是SERVICE机制。
使得即使存在竞争,但是各应用提供的方式不变。
战争虽然存在,但服务依然有效。
就像本文最初提到的图片存储方式,某个图片存储引擎也许无法满足业务性能要求,那么就按照同样的服务接口换一个过去。
好的架构会进化,是进化提供了系统适应环境的能力。
文档化
系统的不可维护通常会因为文档确实,知识的传承缺乏导致。
在ECOS中解决方法有:
1.单元测试的测试用例属于软件包的一部分,单元测试本身就是最好的模块功能文档。
2.文档也属于软件包的一部分,并且统一了文档的格式,甚至某些环境,文档已经成了语法的一部分。
某些函数调用的参数会多出一个,这个参数就是字符串化的文档描述,在程序运行中完全不会被用到,但是如果不写,就会发生错误,这强迫了开发人员必须填写该调用的过程。
7.多语言支持
电子商务必然是个全球化的过程,
ECOS的多语言设计是通过两大步骤,多个角度来完成。
两大步骤即:
国际化:
将软件本身中可能会因地区特性产生差异的因素提取出来,将其“去本地”,也就是国际化,英文常用Internationalization,在i和n中间有18个字符,所以软件行业通常称其为i18n。
本土化:
将已经国际化的中间产品,加上各个所在地的特殊因素,若干角度,比如货币类型,语言,数字分割习惯等等。
这个步骤称为本地化,localization,l和n间有10个字符,常被称为l10n。
ECOS对国际化有着强制性的约定,所有构建于其上的“应用”都必须符合其对国际化的设计。
使得再做其他国家语系时,只要简单做本土化即可。
8.URL路由功能支持下高品质搜索引擎优化
ECOS提供了强大的url路由功能支持,系统会自行检测路由规则,当发现有匹配的路由规则时,会自动解析并重定向。
由于ECOS一切都由APP组成,所以路由规则也是由不同的APP来提供。
ECOS对URL是分段判断,第一级规则是ECOS来判断,后面的路由就完全转交给相关应用。
因此用户可以灵活掌控,比如安装完后,我们可以将'
/setup'
这行注释来屏蔽误操作,当然我们也可以将'
/shopadmin'
改成'
/myadmin'
,自由强大且对程序代码无侵入性。
系统将路由权限交给APP后,此时的APP则成为了规则的制定者,APP作者可以定制不同的路由规则来满足不同的用户需求。
鉴于路由功能的强大,我们可以定制出各式各样的URL,来使搜索引擎更容易理解,达到高品质搜索引擎优化。
举个简单路由的例子,如果我们有一个catalog模块,我们希望能够通过类似下面这样的URL地址来访问具体某个分类:
当然dc.html这个操作是不存的,但我们可以为catalog/*.html配置一个简单的路由规则,将类似的页面都指向catalog控制器,dc则作为控制器的参数调用,轻松实现原本只能通过rewrite才能实现的功能。
以上只是一个最简单的例子,我们完全可以通过程序的扩展来实现更多高级应用。
9.多级智能缓存机制
缓存系统的设计,直接决定了系统的运行效能。
就像我们下了一个订单,送货方如果从悉尼发货和同其在上海的仓库发货相比,速度完全是两个等级。
缓存的设计就在于一个“就近原则”。
将数据靠近使用者。
ECOS的前端站点组件site,对缓存有着极为精细的把控,完全发挥现代浏览器和HTTP协议的性能。
ECOS的site有3层缓存结构,按顺序触发:
层次
缓存名称
存放位置
1
基于http协议的浏览器缓存
用户浏览器本地
2
前台全页缓存
kvcache
3
模板缓存
kvstore
现代浏览器都很聪明,他们尽量不会把同样的数据从网上下载两次。
但是只有同样聪明的服务器程序才能给予配合。
如果用户访问过这个网站,那么ECOS-site会在系统的header头里放一个Etag标签。
这个Etag数据是和页面的内容相关的,如果页面内容变了,Etag也会不同。
这个过程被写在RFC2616文档中:
http:
//tools。
ietf。
org/html/rfc2616
ECOS-site有一个完整的实现,流程如下:
服务器端缓存设计
现在聚焦到上图中"
生成页面内容。
。
"
这个环节中,此时系统并不是为每次生成页面内容的请求都重新运行一次,而是将页面的结果整体缓存下来,如果该页面所包含的数据都没有更新,则是直接输出被缓存下来的内容。
ECOS-site在数据库的操作底层设置了一个触发动作,当有任何表的更新,插入,删除操作时,将当时的时间和被操作的表明记录在一个特殊的表里:
sdb_cachemgr。
例如某时刻该表的数据如下:
表名
最后时间
sdb_goods
2009-11-2116:
20:
26
sdb_goods_cat
2009-11-2005:
25:
21
sdb_setting
2009-11-2319:
40:
13
sdb_member
2009-11-2308:
36:
23
sdb_order
2009-11-2220:
46:
42
sdb_payments
2009-11-2405:
27
实际上,真实系统里表的时间都是unix时间戳格式,那个数字的意思是1970-01-0100:
00:
00之后的秒数。
在这里,为了方便理解,我们在此用实际时间表示。
在处理前台请求时,数据库底层会记录在这个过程中用到的数据表,包括页面挂件,流程插件,自动机器人,模块,以及各种子流程。
同时会记录用到的修改时间,存到最终生成的缓存条目头部。
假设过了5分钟,又有人访问同样的网址,系统发现存在针对这个url的缓存。
此时会读出这个缓存条目用到的表名列表:
sdb_goods,sdb_goods_cat,sdb_setting并到sdb_cachemgr中检查这些表当前的状态,如果发现有以上表里有任何一个在上次缓存保存之后被修改过了,则宣布该缓存作废,重新生成页面。
这个过程是在core/include/cachemgr这个类管理的。
ECOS对CDN和反向代理有很完善的支持
反向代理加速是指在应用服务器前面放置一个加速缓存提升整体性能。
静态内容很容易实现,但动态内容缺面临无法更新的问题。
而在电子商务站点,问题更多:
即使访问的是同一个URL地址,访客的身份不同,语言货币不同,所看到的页面也不同。
这使得传统应用系统最多只能使用CDN做静态内容的加速,而无法使其应用在动态内容上,尤其是电子商务站点。
ECOS对CDN和反向代理有很完善的支持,其设计在于为每个访客计算一个标签。
并将这个标签输出到该用户的COOKIE上。
当该用户在下一次访问时,由最前端的设备(Nginx)将Cookie转换为一个特殊的HTTPHeader,然后再由支持HttpVary的反向代理设备会自动按照该标签对用户进行切分。
使得即使访问同一个URL,不同会员属性看到的内容也是不同的。
参见:
http:
org/html/rfc2616#page-145
应用案例
电商企业的业务是千变万化的,特别是在前端网站部分,更是日新月异,运营部门需要在网站上不断地变化、不断地创新、不断地优化作业和促销方式,这也是我们为什么看到很多电商企业具备自己的开发团队的原因。
商派网络意识到,传统的系统定制方式的一次性交付模式,已经无法满足电商企业的实际需求,如果不作出变革,必然最终会被用户抛弃,因此,电商软件企业必需具备告别传统的勇气和开创新篇的锐气。
通过架构在ECOS平台上的前端B2C系统ECStore,商派网络很好地解决了这个问题,由于完全的应用组件化和开发规范化,ECStore在交付客户后,客户方只要招聘少量较为初级的开发人员经过简单的培训,即可根据运营部门的需求,随时对网站进行变更和优化,同时随着网站的发展,ECOS底层内建特别针对前端的高性能、高可用解决方案即可发生作用,从而替代了以往需要几十人组成的高级架构师和高级工程师团队。
架构在ECOS平台上的后端管理系统OME,充分利用了ECOS所提供的后台界面框架、UI对象库、事件消息队列机制、权限管理机制、业务对象定义机制、应用管理机制,应用扩展机制等进行架构,对相关业务进行变更只需写一个小应用即可完成。
技术指标
我们用9台DellR610作为压力测试环境,测试ECOS架构下的ECStore应用性能承载能力。
ECStore作为基于ECOS的B2C购物系统。
相应速度直接影响订单情况。
我们在安装好ECStore系统后,添加6500条商品,300个商品类别。
然后用典型B2C站点用户访问情况作为压力测试分布规则,规则如下:
•20%首页
•30%商品详细页(随机)
•10%商品类别页(随机)
•30%商品搜索(随机)
•5%渐进式商品过滤
•5%管理员后台操作
测试结果如下:
网络流量(纯html)
CpuLoad
页面响应时间
页面响应情况
测试结果表示,在4台WEB,2台数据库的情况下,2台kv+搜索服务器,1台LVS的情况下。
可以支撑每秒1000的请求量,即1000QPS。
并且随着访问量的增加,预热的时间越长,缓存的作用就体现的越明显,相应时间越来越少,但是随着变数查询的增加,CPU负载也是一路走高,但仍在可承受范围内。
换算到业务考虑的峰值压力过大,因此按每天10个小时计算。
是1000*3600*10=36,000,000即3600万请求每天。
如果放上反向代理设备,这个数据可以直接翻倍。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ecos 技术 白皮书