Ⅰ 大型互联网公司项目如何架构
初始阶段的网站架构
大型网站都是从小型网站发展而来，网站架构也是一样，是从小型网站架构逐步演化而来，小型网站最开始没有太多人访问，只需要一台服务器就绰绰有余，这时的网站架构如图。
应用程序，数据库，文件等所有的资源都在一台服务器上。通常服务器操作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySql，汇集各种开源软件及一台廉价服务器就可以开始网站的发展之路了。
应用服务和数据服务分离
随着网站业务的发展，一台服务器逐渐不能满足需求：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，这时就需要将应用和数据分离，应用和数据分离后整个网站使用三台服务器：应用服务器，文件服务器和数据库服务器，如下图所示，这三台服务器对硬件资源的要求各不相同，应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU,数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存，文件服务器需要储存大量用户上传的文件，因此需要更大的硬盘。
应用和数据分离后，不同特性的服务器承担不同的服务角色，网站的并发处理能力和数据存储空间得到了很大改善，支持网站业务进一步发展，但是随着用户逐渐增多，网站又一次面临挑战：数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验受到影响，这时需要对网站架构进一步优化。
使用缓存改善网站性能
网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%的数据上。淘宝买家浏览的商品集中在少部分成交数多、评价良好的商品上；网络搜索关键词集中在少部分热门词汇上；经常登录的用户才会发微博、看微博，而这部分用户也只占总用户数目的一小部分。
既然大部分的业务访问集中在，那么如果把这一小部分数据缓存在内存中，就可以减少数据库的访问压力。网站使用的缓存分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数量有限，而且会出现和应用程序争用内存的情况。远程分布式可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务。
使用缓存后，数据访问压力得到有效缓解，但是单一应用服务器能够处理的请求连接有限，在网站的访问高峰期，应用服务器会成为整个网站的瓶颈。
使用应用服务器集群改善网站的并发处理能力
使用集群是网站解决高并发，海量问题的常用手段，当一台服务器的处理能力、储存空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求，这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。
对网站而言，只要能通过一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性，应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种。如下图所示。
通过负载均衡调度服务器，可将来自用户浏览器的请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不在成为网站的瓶颈。
数据库读写分离
网站使用缓存后，大部分数据操作访问都可以不通过数据库就能完成，但是仍有一部分读操作，(缓存访问不命中、缓存过期)和全部的写操作，需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。
应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库或得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离时对应用透明。
使用反向代理和CDN加速网站响应
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，是用户在请求网站服务时，可以从距离自己最近的网路提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接给用户。
使用分布式文件系统和分布式数据库系统
分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用，不到万不得以时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。
使用NOSQL和搜索引擎
对于海量数据的查询，我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb和redis，搜索引擎有lucene。
业务拆分
随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如网络分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者同享数据库来实现.
分布式服务
这时我们发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。淘宝的Dubbo是一个不错的选择.
Ⅱ 开发大型网站需要注意什么
在实际操作中，一个大型网站开发项目有数十人并同工作，项目过程被分解成几个部分，尽管如此，归根到底还是这几个工作流程在并发进行。
方法/技巧
程序框架：我们想开发的网站，往往市面上会有很多同类的开源程序，所以大家选择程序上并不难，但是大家不要随便的选择了一个框架，要看该程序的二次开发性能、弊端、结构优化等几方面是否适合自己。以及网站未来发展规划，都要考虑在内。所以选择程序不是意见简单的事情。
开发过程：对前台开发大家都知道要用到设计师、网站布局人员、JS工程师等等还有。。我这里就对JS方面阐述一下，大型网站得对前端有一个整体规划，所以JS规划是不可缺少的，以下我自己归纳的3种JS编写方案：
1、零散型：什么是零散型的呢，这是我自己定义的，就是说当我们用到什么效果的时候就去针对性的写一块，这样的好处是方便，省事，哪里需要就在哪里写，也不用外部文件调用，对于JS要求不多的网站来说很实用，缺点是不好管理，修改代码时候往往会找不到代码。
2、封装型：和零散型区别是，把代码都封装起来，用文件调用，封装好处是，不和别的函数发生冲突，做成一个个的封装类，很实用，现在大多数网站是用这种方法。缺点是，仍然不是一个整体的类库，但要比零散的好管理的多，因人而异吧。
3、JS类库：JS类库很多，用的比较多的有prototype，jQuery，我们拿jQuery举例，现在大型网站总的来说用JS无非是两种方式，一个是原生JS，纯JS编写的网站(以上的两种方法包含在内)，再就是利用jQuery框架，两种方式过程是截然不同的，但是用户看到的效果却是一样的，有的大型网站单纯就是JS编写，不用任何框架，这是一种技术上的硬性标准，对于不同的公司而言，这样做是对单纯技术上的考验，高手很多，用JS同样能写出和jQuery一样的类库，但是如果用jQuery的话就会节省大量的时间，因为jQuery本身就有很多的插件供大家使用，完全开源。不过另一方面说，jQuery可能确实是属于应用的APP，和自己编写的代码是有本质区别的。我看过很多有名的网站，有JS和jQuery结合的，有单纯JS的，也有纯jQuery的，不管怎么使用浏览者所看到的效果是一样的，区别是我们在扩展上、维护上、管理上是有区别的。所以大家写前端代码时候用到的JS要谨慎考虑，也要根据自己的能力来判断该如何使用JS。
团队配合：好的产品是离不开整个团队配合的，因为你不是一个人在战斗。在技术开发上，要时刻保持沟通，哪怕一丁点问题，能问同事就多问，一句话的事情总比去网络上找强吧，特别是核心上的问题，策划上的问题，不能自己单方面的去想，要一起来决定这件事是否正确，是否可以实施。往往返工就因为配合的不默契导致技术上失误，造成时间的开销和领导的指责。要记住，自己在怎么有能力，也不会胜于整个团队的努力。
找BUG：BUG在技术领域上是很热的一个词了，我们开发过程中，每时每刻都在找BUG，BUG也是无形中发现的。发现一个BUG有时候甚至要比你学了好几天的东西要强的多，因为BUG是你最容易忽视的问题，你学漏的知识。产品发布有时候会因为一个BUG降低知名度、权威度。所以在产品发布之前，找BUG是最重要的，但我想说的是，找BUG不是要专门等到一定的时机在去找，我们要在工作中，休息中，睡不着觉的时候都应该来想，今天我写了什么代码。会不会有问题。这个时间是比专门腾出来的时间找BUG要多的多。这是技术上的细节，我们要利用有效的时间做一些无限的事
Ⅲ 网站的基本架构是什么
网站架构按照制作步骤分为硬架构和软架构。
一、硬架构
1、机房：在选择机房的时候，根据网站用户的地域分布，可以选择网通、电信等单机房或双机房。
2、带宽：预估网站每天的访问量，根据访问量选择合适的带宽，计算带宽大小主要涉及峰值流量和页面大小两个指标。
3、服务器：选择需要的服务器，如图片服务器，页面服务器，数据库服务器，应用服务器，日志服务器，对于访问量大点的网站而言，分离单独的图片服务器和页面服务器相当必要。
二、软架构
1、网站的框架：现在的PHP框架有很多选择，比如：CakePHP，Symfony，Zend Framework，根据创作团队对各个框架熟悉程度选择。
2、逻辑的分层
1）表现层：所有和表现相关的逻辑都应该被纳入表现层的范畴。
2）应用层：主要作用是定义用户可以做什么，并把操作结果反馈给表现层。
3）领域层：包含领域逻辑的层，就是告诉用户具体的操作流程的。
4）持久层：即数据库，保存领域模型保存到数据库，包含网站的架构和逻辑关系等。
(3)大型网站核心架构怎么解决问题扩展阅读
网站的分类
1、根据网站所用编程语言分类：例如asp网站、php网站、jsp网站、Asp. net网站等；
2、根据网站的用途分类：例如门户网站（综合网站）、行业网站、娱乐网站等；
3、根据网站的功能分类：例如单一网站（企业网站）、多功能网站（网络商城）等等。
4、根据网站的持有者分类：例如个人网站、商业网站、政府网站、教育网站等。
5、根据网站的商业目的分类：营利型网站（行业网站、论坛）、非营利性型网站（企业网站、政府网站、教育网站）。
Ⅳ 大型网站技术架构 核心原理与案例分析 有用么
编辑推荐
编辑
本书作者是阿里巴巴网站构建的亲历者，拥有核心技术部门的一线工作经验，直接体验了大型网站构建与发展过程中的种种生与死，蜕与变，见证了一个网站架构从幼稚走向成熟稳定的历程。
没有晦涩难懂的术语，没有诘屈聱牙的文句，没有故弄玄虚的观点……
明明白白的语句，清清楚楚的文法，干净利落的建议——让读者直接体会网站架构的紧要处，不容马虎的关键点——这恰好是一个优秀的网站架构所必备的要素。
如果说“水不在深，有龙则灵”，那么对于想了解网站架构的读者而言，这本书恰好是“书不在多，有它则行！”
还犹豫什么呢？
内容简介
编辑
本书通过梳理大型网站技术发展历程，剖析大型网站技术架构模式，深入讲述大型互联网架构设计的核心原理，并通过一组典型网站技术架构设计案例，为读者呈现一幅包括技术选型、架构设计、性能优化、Web 安全、系统发布、运维监控等在内的大型网站开发全景视图。
本书不仅适用于指导网站工程师、架构师进行网站技术架构设计，也可用于指导产品经理、项目经理、测试运维人员等了解网站技术架构的基础概念；还可供包括企业系统开发人员在内的各类软件开发从业人员借鉴，了解大型网站的解决方案和开发理念。
Ⅳ 大型网站架构该怎么优化设计
你得把你的网站拿出来看了才知道怎么优化改进。并不是说每个网站的优化思路都一样。比如，你优化结构之前你得考虑你的长尾关键词要怎么扩展，长尾词是不是有规律可循。如果有规律，你可以直接利用程序生成标题，生成内容。要根据你的设计思路去设计网站结构。要是每个网站优化思路都一样，那为什么不直接程式化，还拿优化运营来做什么？自动化多好。但是，这是不现实的。所以，你的提问没人能帮得到你。
Ⅵ 关于大型网站架构问题
1、HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。
同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。
2、图片服务器分离
大家知道，对于Web服务器来说，不管是APACHE、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadMole，保证更高的系统消耗和执行效率。
3、数据库集群和库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。
在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MYSQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。
上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。
4、缓存
缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存,LINUX上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用JAVA开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。
、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和ENet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。
硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。
软件四层交换
大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。
软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。
一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。
对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。
其实这样的手段还很多,总结:第一,页面静态化(CMS)
第二,用镜像或者CDN(这一块可以付费完成)
第三,数据库库表分离,并且部署多台数据库服务器集群
第四,分化服务器,分成WEB服务器,FTP服务器,图片服务器,DNS服务器.
第五,DNS服务器,分流到各功能应用服务器(如博客,论坛,问答)
此外,这样的手段还有很多....注意重点学习,你一定会有所成就
Ⅶ 大型网站架构设计
大型网站架构设计是非常复杂的事情，一个近千万用户的网站自然在各个方面与传统的网站有着必然的区别。
网站静态。一个每天有着数千页面的网站也要实现静态化的页面，这只有依托一些程序来自动实现了，人工完成这样的工作是几乎不可能的。
系统架构。一个大型的网站要在内容上可以不断的扩充，要在结构上进行不断的深入发展，这就需要进行一个很好的优化，而对于数据库或者网站程序都要全面的进行统一的规划与筹备，这就需要一个团队一起为了一个目标而努力。
存储。一个网站如果做到很大的规模，它的存储也应该进行统一的规划，图片如何存储，信息如何存储，来自各个搜索引擎的索引如何设置等等，这都要进行一个合理的分配。
数据库技术。大的网站每天有着巨大的流量，在访问的需求方面也是非常突出的，我们要用必要的数据库技术来应对这些巨大流量的挑战，从而让网站的浏览体验保持良好。www.21-mars.com采用了库表散列就解决了大数据的问题。
Ⅷ 网站架构的问题
直接开一个商城算了
Ⅸ 网站结构该怎么去优化 关于当当网架构优化的几点心得
第一点：用户体验。
我觉得这是SEO里的重点，因为如果一个用户体验都不良好的网站，搜索引擎也不会认为你是一个好的网站，搜索引擎的排名算法有很大程度的去考虑用户体验的。所以我们建设一个网站要让用户访问到我们的网站中能够很清楚的自己在什么地方，接下来要去什么地方，很方便的点击链接，得到他想要得到的信息。假如你进一个网站，网站内部混乱不堪，没有清晰的导航，没有你像看到的信息锚文字，你是是不是也会不假思索的关闭这个网站，去寻找另一个网站。
第二点：收录量。
我们进行网站结构优化的目的就是利于SEO，SEO的最基础前提是你的网站有收录，如果一个良好的网站结构，搜索引擎蜘蛛也很容易爬行到你的网站内页对你的网站进行收录，像我的tuihongbao.cn这个网站网站结构就是很清晰的，虽然收录量不是很(尴)大(尬)。
第三点：网站权重的分配。
网站的哪些内容是你最想给用户展现的，哪些内容是比较次要的，那么这个在网站结构规划的时候，就要对网站进行权重分配，权重高的网站自然排名就会比较高。这样才能突出我们的主要业务。
第四点：锚文字。
要说网站的站外锚文字自己控制不了，那么在站内，锚文字站长都是可以控制的。为什么要达到锚文字清晰的目的，因为锚文字是搜索引擎排名中很重要的一部分。
关于当当网架构优化的几点心得
第一，对技术部组织架构进行调整。
将原来的职能化组织中的产品、研发和测试部门按照产品线进行整合，转型为Unit化，以加强同一产品线不同职能团队之间的配合协作，沟通更高效，团队更为聚焦。
这样的组织结构更易于应用敏捷，与实施敏捷的前提同理，产品线拆分建立在系统架构解耦基础之上，在这一点上，系统架构与组织架构异曲同工且相辅相成。解耦越充分，系统边界越清晰，模块越小，越适合敏捷团队，能够快速响应业务需求。
业务相近的产品线组成一个产品研发部，这样多数的小型需求在部门内就可以解决，面对紧急项目还可以灵活使用人力资源，并为员工创造接触更多类型业务需求的机会。
第二，系统分层依赖。
随着业务逻辑越来越复杂，系统越来越多，相互依赖也越来越多。比如我的当当中就聚合了安全中心、用户、账户、订单、收藏夹、推荐等多维度的信息，需要调用多个系统服务。经过讨论，决定将用户交互层面的前端页面与原有的后端系统拆分，并入前端的产品线，以便为用户提供更好的服务。
而后端系统之间的依赖关系也需要更为精细的分层定义，对于促销系统，需要会员系统、订单系统、价格系统提供基础数据;对于运费系统需要商品信息和配货数据，而在精准定位销售区域的前提下，库存只是配货的基础数据，配货系统负责判断是否有货，Promise则根据配货结果计算预计送达时间。
调整系统之间的关系是很难的，牵一发而动全身，但重构是契机，2015年，对于电商的核心系统交易和促销进行了重构，同时价格、配货、运费等系统也进行了较大调整，从而使系统间依赖问题得到了明显改善。
第三，服务化。
微服务为互联网行业的服务化指明了方向，也坚定了我们进行服务拆分和解耦的决心。
原有的架构以系统为维度，服务归属于明确的系统，而系统的划分一般以业务功能为聚合，随着业务的发展，新的业务功能层出不穷，总会有一些打破原有的系统边界，给架构提出难题。
服务化，不仅是指系统将能力通过服务对外提供，更重要的是服务本身就是承载业务功能的单元，如果有组合了多个逻辑难以归入某系统的服务，不必纠结，作为独立的业务模块开发就是了，以服务为单元，系统架构更加扁平，简单清晰。
微服务架构中，服务粒度会更小，服务治理的需求更加迫切，更需要技术手段解决，比如分布式服务框架，当当使用的是基于Dubbo二次研发的DubboX，以及结合ddframe实现的服务调用监控。
去年的容器技术爆发，为微服务架构实施提供了有力工具，当当内部也在部分系统使用了Docker。
微服务大势所趋，秉承SOA理念，在服务治理中心的基础上，将系统弱化，提供更多的基础服务，提高了系统的复用性和灵活性。
第四，平台化。
平台化包括两个维度，技术平台化和系统平台化。
技术平台化是指在技术层面建立统一的体系，包括根据行业特点进行技术选型，使用稳定可靠的技术组件。
当当从2012年开始将原有的.net平台向Java平台迁移，从封闭到开源，应用电商行业的主流技术栈，到2015年，基本完成了技术转型，主要后端业务系统都转移到Java平台。
经过数年的积累，2015年当当架构部研发了Java应用开发框架ddframe，目的是分离技术和业务，封装技术细节，将应用开发人员的精力集中在业务开发上。
随后再接再厉，当当架构部又推出了用来替代TBSchele的分布式作业调度框架Elastic-Job。并将之开源，基于JDBC的分布式数据库中间件Sharding-JDBC也在开发中。
统一的技术栈，能够复用技术资源，持续积累整体的研发能力，为做精做专提供更好的基础条件。
系统平台化是指搭建基础平台，包括测试平台、分布式服务平台、自动化运维平台、监控平台、缓存集群、消息中间件平台、大数据处理平台、项目管理系统、日志平台、问题跟踪系统等。
基础平台是各业务系统有机协作的基础，保证了整个技术架构的全面可控，能够降低系统运维复杂度，是大型电商系统不可或缺的组成部分，良好的基础平台是技术实力和管理能力的双重体现，而多数公司更注重业务，会在基础平台建设方面欠下许多技术债务。
2015年，当当搭建了自动化运维平台Pangu、监控平台Radar，重构了项目管理系统，Redis集群管理平台也在搭建中。
第五，核心系统重构。
在电商业务发展的快节奏之下，核心系统持续迭代是常态，而且基本两、三年以上，就需要考虑重构，否则难以支撑业务的快速变化。
另外，系统重构集中梳理业务逻辑和系统依赖，整理统一的文档，剔除无用功能，归并多个版本，甩掉历史包袱重新设计架构，适度的前瞻性设计使系统在一定周期内具备业务扩展性。
2015年，当当完成了交易系统和促销系统进行了重构。
交易系统在2015年10月底完成新老版本切换。重构耗费约1500人天，重构代码17万行，全部切换至Java开源技术架构，为公司节约大量成本，并进行了架构优化，整体性能平均提升25%，经受住了双十一和双十二的考验。
在当当，有一些“类促销”业务，从广义上可以归入促销范畴，但业务与数据均不属于促销系统，在促销系统重构设计中，我们考虑将这类业务逐渐回收;另外，促销系统能不能承担一些营销的功能?带着这两点考虑，在促销基础上进一步抽象出活动模型。
Ⅹ 大型网站建设过程要注意什么问题
随着互联网的发展对我们的生活也有很大的提升，但是现在互联网上的网站有很多，想要建设一个更好的效益较大化的网站。一个网站的建设能不能满足用户的需求，同时有良好的体验呢？这都是大型网站建设要考虑的问题。
大型企业门户网站建设首要目的是要展示企业的形象，宣传企业文化扩大行业内的影响力。网站制作注重企业的稳定性和丰富的信息量，配合旗下的产品和主打系列进行联合推广，部分网站建设在此基础上添加了旗下产品的在线商城建设和交流平台建设。 大型企业门户网站建设主要是为浏览者提供信息服务的，作为大型企业信息门户网站，必须首先提供种类繁多内容丰富的资讯，使不同的访问者都能够访问到自己想要的信息。
一、首页设计很重要
网站首页就像一个人的整体面貌，所以相当重要。大型网站建设，自然要竖立好自己的形象，所以在设计上一定要保持干净简洁的风格，并且是类别鲜明。一般网友们浏览网页，都是希望找到吸引自己的东西然后进行阅读，如果网站首页类别不鲜明，让网友找了很久都无从下手，不知该如何进入主题，那这个首页就太失败了。并且首页也尽量不要放太多的FLASH和图片，这样不仅会给网友浏览网站带来视觉障碍，也会延长缓冲时间，消磨网友的耐心。所以，可以总结出，网站首页风格要简洁鲜明，并且内容要直白清楚，能一下子进入正题，给阅读的人一个直接的解释，让人对这个网站有一个初步的正确的印象。
二、设计和策划的准确性和完整性
网站建设是要先经过策划和设计的，通过需求文档才能继而锁定功能的设计，通过设计网站整体框架，才能有序进行网站的建设。没有计划而盲目地实行建设，最后一定会产生很多漏洞。由此可见，网站建设离不开各种策划和设计，而这些策划和设计的准确性和完整性也决定了整个工程的成败。做什么事规划都是很重要的，在开始实质工作之前，必须要确定自己网站需要什么适合什么，才能根据自身的特色顺利开始建设工作。
三、程序要选好框架
网站建设必然要用到程序，而如今网络上各种程序都不缺，一般网站建设的开源程序都有很多，所以在程序方面上并不难解决，但是需要注意的是，任何选择都需要有前瞻性，考虑到程序的各方面，例如利弊、二次开发性等等，还有是否适合自己的网站，所以程序的选择也需谨慎对待。
四、时刻记得找漏洞
一个小小的BUG可能造成整个程序无法运行，而这个小小的BUG偏偏在整个程序中很不起眼，难以让人察觉，这是个很让人头痛的问题。所以，在开发和建设过程中，要时刻记得寻找漏洞，不然等到所有工作都做完了再去运行，结果发现出现了问题，从头找起，那时候的工程实在是很浩大。BUG往往是很容易忽视的地方，所以在整个过程中都要保持时刻的认真和谨慎，当然再谨慎的人也没法保证不出错，所以后期的找错工作不能马虎。
五、团队配合很关键
一个大型网站的开发不可能由单人作战完成，一定是需要一个团队的合作才能做好的。在开发和建设过程中一定要时刻注意团队问题。在技术方面，要经常交流和沟通，毕竟一个人的力量是有限的，经常和队友交流技术的经验和感想，也能解决很多技术上的问题。另外，在策划和后期运行维护之类的工作中，也需要团队交流，只有协调了团队所有人的想法，之后的工作才不会有冲突，只有所有人明确了各方面的任务，之后如果工作出现问题才能更容易地解决。