中小型电子商务网站架构
一个小型的电子商务网站,例如日交易量5万订单以下,或者说每天差不多五千万个pv左右。我们可以讨论下,整个架构应该如何设计。
业务分离,域名分离
现在好的电子商务网站都是按照业务分开,细化每个业务线。这样有利于系统的扩展,也有利于对系统的维护。例如:商品可以独立出来,交易独立,用户独立等等。各个系统之间需要交互的信息可以通过远程传输来实现。在一个比较有规模的团队中,最好有个组专门来维护一个独立的业务,有利于团队对业务渗透和业务的维护。
由于业务分开,系统分开,当然在域名上也应该分开, 例如:整个网站的域名为www.abcd.com。那商品系统域名就应该为item.abcd.com。交易可以使用order.abcd.com。这样的好处显而易见,在访问上就可以分流。很多公司是通过www.abcd.com/item这样处理,所有流量都统一进入www.abcd.com然后再处理,这样对主服务器压力就非常大。这个道理很简单。就像一个口小身大的瓶子一样,水很难灌进去。现在很多电子商务公司都没有意识到这个问题。这些简单的方法都没有注意到。
独立搜索引擎
最近几年很多人都习惯于通过搜索找到自己喜欢的东西,一个好的网站一定要有独立的搜索引擎,分词要好,实时数据更新最好,最好做成分布式搜索。为了能够准确定位商品,对商品一定要有非常完善商品属性,例如:我在搜索一件红色 夏季的衣服,我就会输入红色 夏季进去,如果商品没有颜色属性,没有季节属性,就无法定位到我想要的商品上面。除了完善的商品属性,还应该建立比较好的推荐搜索,保持关键字推荐,搜索结果推荐。
搜索是一个非常庞大和奥妙的课题,本人知之甚少,也不好班门弄斧。我是做java出身,经常使用Lucene也很喜欢Lucene。很多人都误会Lucene做搜索不够强大,其实技术要做好,一样很强大。twitter就是使用Lucene做搜索,也比较强大了,熟能生巧。
数据架构
数据架构范围太大,太广,起这个标题有点大题小做了。其实一个比较大的系统,最起码的数据架构要求就是数据库拆分。垂直划分很简单,就按照业务分成不同的数据库。另外一种是水平划分,把同一个业务数据划分到不同的数据。到最后就应该是可以考虑读写分离,读写分离就好像高速公路一样,左右车道分开,中间有隔离带,当然速度就上去了。
在我的博客上有一篇文章主要讲读写分离。
缓存数据
缓存是我最喜欢的的技术,也是目前很多系统都会使用到的技术,为了提高系统性能,提高速度,缓存使用必不可少。最有名的莫过于memcache啦,淘宝的tair也很不错。这些都是大型分布式缓存,其实如果是小型系统,可以自己开发缓存,可以根据业务要求,把对应的数据放到内存中,就可以了。其中技巧很多,一切都以合适场景为主。
还有另外一个现在非常流行的技术就是cdn缓存,提供商很多,淘宝比较牛,自己开发cdn,而且架构也非常好。
说到缓存还有静态页面缓存,浏览器客户端缓存。等等,这些都可以在一定程度上提高性能。
异步通信系统
在一个分布式系统中,系统之间交互必不可免,就会涉及到很多系统之间消息同步,状态同步,消息记录等,一个好的异步消息系统,可以很好提高系统的强壮性和扩展性。例如为了保证数据或者状态一致性,通过消息系统就可以保证数据一致。在交互时,向消息队列中提交对象,再进行系统之间状态交互。就算系统状态 失败消息中也保证了对象的存在。在上面提到的读写分离中,就可以通过异步消息系统做数据同步。
完善的系统监控
在一个比较大型的分布式环境中,一定要有监控系统。例如:流量监控,硬件监控,系统性能监控,如果再深入的话,可以对某个页面进行监控,设置页面的其中一块进行监控。特别在硬件监控或者性能监控时如果发现异常,就应该预警,这样也好防范于未然。
一个好的系统其实应该从扩展性、安全性、性能和可靠性来考虑,其中三言两语说不完。架构适合就好,可以采用先行之而后优。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Dubbo在Service Mesh下的思考和方案
开头 Service Mesh这个“热”词是2016年9月被“造”出来,而今年2018年更是被称为service Mesh的关键之年,各家大公司都希望能在这个思潮下领先一步。今天我也分享阿里中间件在这方面的观点,思考和实践。考虑到有些人没了解过Dubbo(集团内以HSF为主)和Servicemesh,先简单介绍下这两个词。Dubbo应该是国内最受欢迎的远程服务框架,在Github上有超过2w的star数,也是阿里分布式架构互联互通的核心所在。跟Dubbo一样,servicemesh也是面向服务互联互通这一问题域,是云原生技术栈的核心之一;大家可以简单理解service mesh就是云原生组织定义的微服务架构解决理念。Dubbo是实现框架,融入servcemesh理念就是我们今天分享的。 现状和挑战 当前Dubbo支撑的阿里分布式应用内支撑万级别的应用数,运行在20多万的服务器实例上,每天调用量是万亿级别,这应该是国内最大的分布式应用集群。 挑战主要来自三方面 首先, 数以万计的应用意味着有以十万级的服务,理顺错综复杂的服务拓扑关系,甚至及时诊断某个异常调用链路,需要考虑海量数据的拉取分...
- 下一篇
程序员职业危机,到底是什么使得同是程序员差距这么大?
程序员的30岁现象 在官场上,曾经有一个59岁现象,就是官员们会在59岁时,会使劲捞上一把。很明显嘛,权力过期作废,再不捞就要退休了,没有机会了。 在程序员的圈子里,也有一个30岁现象。程序员干到30岁,好不容易从码奴混到了白领,却再也干不动了,还时时面临失业的危险。30岁,是一个程序员伤不起的年龄。明天,何去何从?当然,如果你有铁饭碗,比如在国企或政府机关,那你是无法理解底层劳动人民的感受的。同时也要恭喜你成为体制内的一员,可以一直干到退休无忧。 30岁现象人人都明白,但要给出一个定义并不容易。列举几个表现,也许你会觉得心有戚戚焉。 面临职业瓶颈,程序写不动,上升又困难。 薪水较高,加班变少,后浪追前浪,面临失业压力;生活压力剧增,不敢跳槽; 招聘程序员年龄限制在30岁以下成为行业潜规则,跳槽困难。 30 岁现象和59岁现象貌似不搭边,其实都出于同样的原因:价值贬值。官员老爷在任就像皇帝,一旦退休,就成为了平民百姓,贬值那是自然的。而程序员也一样, 所谓三十而立,一旦到了30岁左右,由于面临结婚生子,一方面需要高薪抚养家庭,另一方面却无法像以前那样全身心投入到工作,性价比急剧下降;与...
相关文章
文章评论
共有0条评论来说两句吧...