web门户网站架构需要注意些什么？
0
最佳答案
0
|
妇孺皆知，对于一些相对小的站点来说，数据量并不是很大，select与update即可以计划咱们面对的题目，本身负载量不是很大，至少再加几个索引即可以搞定。关于大型站点，每天的数据量可能就上百万，若是一个设计欠佳的多对多关连，在后期是不有任何标题的，可是随着用户的增多，数据量会是几何级的增长的。在这个时候我们关于一个表的select与update的时辰(还不说多表会萃查问)的成本的非常高的。 大型web架构紧要注意和思忖的题目：2、数据并发的处理 在一些时候，2.0的CTO都有个尚方白?，就是缓存。对付缓存，在高并发高处置的时分也是个大标题。在整个使用法式下，缓存是全局同享的，然而在咱们进行修正的时刻就，要是两个可以多个乞请同时对缓存有更新的申请的情况下，应用措施会直接的死掉。这个时候，就需求一个好的数据并发处理战略以及缓存策略。 另外，等于数据库的死锁问题，也许日常咱们感应不到，死锁在高并发的状况下的出现的几率是非常高的，磁盘缓存等于一个大题目。 大型站点架构重要留心和思量的题目：3、文件存贮的标题 对付一些支持文件上传的2.0的站点，在声誉硬盘容量愈来愈大的时候我们更多的理当思虑的是文件应该如何被存储而且被无效的索引。常见的方案是对文件按照日期和类型进行存贮。可是当文件量是海量的数据的状况下，假如一块硬盘存贮了500个G的琐碎文件，那么护卫的时分和使用的时刻磁盘的Io就是一个庞大的问题，哪怕你的带宽虚假，然则你的磁盘也定然相应过来。假如这个时刻还波及上传，磁盘很简单就over了。 也许用raid和专门使用存贮管事器能筹算眼下的标题，可是尚有个题目等于各地的走访标题问题，也许我们的效能器在北京，可能在云南或者的访问速度如何企图?假如做分布式，那末我们的文件索引以及架构该若何规划。 所以咱们不得不招认，文件存贮是个很不简单的题目 大型站点架构需求把稳和思虑的标题：4、数据关连的措置 咱们可以很容易的规划出一个契合第三范式的数据库，内中布满了多对多相关，还能用GUID来革新INDENTIFY COLUMN 然而，多对多干系充溢的2.0时代，第三范式是第一个应当被扬弃的。必需无效的把多表紧凑查询降到最低。 大型站点架构重要留神和思考的问题：5、数据索引的题目 享誉中外，索引是进步数据库效用盘诘的最方面最廉价最容易实现的方案。然则，在高UPDATE的情况下，update与delete收入的资本会高的无法想一想，笔者碰到过一个状况，在更新一个聚焦索引的时辰紧要10分钟来完成，那末对于站点来说，这些底子上是不成忍受的。 索引和更新是一对天生的伴侣，问题A，D，E这些是咱们在做架构的时辰不能不思索的标题问题，何况也多是花销年华至多的问题， 大型web架构必要留意与思量的题目：6、分布式措置 关于2.0站点因为其高互动性，CDN实现的成果基础上为0，内容是实时更新的，咱们通例的处置。为了担保各地的会面速率，我们就须要面临一个绝大的标题问题，就是若何无效的完成数据同步与更新，实现各地干事器的及时通信有是一个不得不必要思忖的标题问题。 大型web架构重要把稳与思忖的问题：7、Ajax的利弊分析[哈尔滨发票(http://www.99haerbin.com/)] 成也AJAX，败也AJAX，AJAX成了主流趋势，忽然创造基于XMLHTTP的post与get是如斯的容易。客户端get或是post 到供职器数据，效能器接到数据乞求以后前去来，这是一个很正常的AJAX苦求。然而在AJAX措置的时刻，若是咱们使用一个抓包工具的话，对数据前往和处置是若隐若现。关于一些较量争论量大的AJAX恳请的话，咱们可以布局一个发包机，很容易就能够把一个webserver干掉。 大型web架构重要把稳与考虑的问题：8、数据平安性的赏析 对于HTTP协定来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，可是对于G标题来说的话，加密的历程就可能是明文了(比方我们知道的QQ，可以很容易的果决他的加密，并有效的写一个跟他同样的加密与解密方法出来的)。当你站点流量不是很大的时辰不有人会在乎你，可是当你流量下去之后，那么所谓的外挂，所谓的群发就会接踵而来(从qq一开端的群发可见端倪)。也许我们可以很的意的说，咱们可以接纳更高级其它武断以致HTTPS来完成，留意，当你做这些处理的时辰付给的将是海量的database，io以及CPU的资本。对于一些群发，根蒂上是不成能的。笔者也曾可以完成关于baidu空间与qq空间的群发了。人人乐意尝尝，实践上并非很难。 大型站点架构紧要留神与思索的题目：9、数据同步与集群的措置的标题 当咱们的一台databaseserver不胜重负的时分，这个时候我们就需要做基于数据库的负载和集群了。而这个时分可能是最让人骚动扰攘侵犯的的题目了，数据基于网络传输根据数据库的设计的差异，数据延宕是很阴森的标题问题，也是弗成提防的标题问题，这样的话，我们就紧要颠末另外的本事来保障在这延宕的几秒可以或许更长的几分钟岁月内，完成无效的交互。譬如数据散列，分割，模式处理等等标题 大型web架构重要当心与思量的题目：10、数据同享的渠道以及OPENAPI趋向 Openapi也曾成为一个不成防备的趋势，从谷歌，facebook，myspace到国外校内，都在思考这个标题，它可以更有用的留住用户并诱发用户的更多的兴味以及让更多的人扶助你做最有用的开荒。这个时辰一个无效的数据同享平台，数据开放平台就成为必不成少的阶梯了，而在开放的接口的状况包管数据的平安性与性能，又是一个咱们必重要经受思考的问题了。 |
收获园豆：50
thank ，从数据方面说的很多。
其他回答(1)
0
你这个图不是已经很清楚了吗？
再提一点疑问，前端的数据访问层是什么鬼？
后端写接口？是指controller到biz层用不用加service层？建议加上，因为看你要做的是门户网站，如果后期用户访问量上来之后，就要考虑高并发问题，可能用分布式，service可以使用dubbo管理，就更加方便。
对于上图，OData/JData 不是很清楚，因为是看的别人的也没请教···
前段数据访问层怎么实现也不是很清楚哇（暂且略过···），后端接口是指根据前端业务怎么具体写？
service 层的已经写了，后期访问量上去之后（暂且不考虑）。
项目目录结构大概这样子的：
@user_peng: OData/JData我没听说过啊，百度了一下，好像是.net的东西，不是很清楚，另外你说的接口，是什么接口啊？webservice？我感觉你是不是误以为了什么啊？后端不需要什么接口的啊。另外，看你这个项目目录结构，好像没有biz（业务处理层啊）。
@灵魂盗猎者:
试问我这个结构的service 层和biz 层有区别吗？
@user_peng: 都可以了，如果想分的更细一些，可以这样，controller层只做请求的接收和服务的调用，service做参数的解析和校验，然后调用biz层，来做业务处理，biz掉Mapper进行数据的持久化操作。这个biz和service区分没有那么明显。因为我工作中都是service、然后biz的，所以习惯性的感觉service下少了个biz。不用也可以，没有什么区别。。。。
@灵魂盗猎者:
噢，原来如此，懂了，多谢指教！
