网站结构该怎么去优化 关于当当网架构优化的几点心得

第一点：用户体验。

我觉得这是SEO里的重点，因为如果一个用户体验都不良好的网站，搜索引擎也不会认为你是一个好的网站，搜索引擎的排名算法有很大程度的去考虑用户体验的。所以我们建设一个网站要让用户访问到我们的网站中能够很清楚的自己在什么地方，接下来要去什么地方，很方便的点击链接，得到他想要得到的信息。假如你进一个网站，网站内部混乱不堪，没有清晰的导航，没有你像看到的信息锚文字，你是是不是也会不假思索的关闭这个网站，去寻找另一个网站。

第二点：收录量。

我们进行网站结构优化的目的就是利于SEO，SEO的最基础前提是你的网站有收录，如果一个良好的网站结构，搜索引擎蜘蛛也很容易爬行到你的网站内页对你的网站进行收录，像我的tuihongbao.cn这个网站网站结构就是很清晰的，虽然收录量不是很(尴)大(尬)。

第三点：网站权重的分配。

网站的哪些内容是你最想给用户展现的，哪些内容是比较次要的，那么这个在网站结构规划的时候，就要对网站进行权重分配，权重高的网站自然排名就会比较高。这样才能突出我们的主要业务。

第四点：锚文字。

要说网站的站外锚文字自己控制不了，那么在站内，锚文字站长都是可以控制的。为什么要达到锚文字清晰的目的，因为锚文字是搜索引擎排名中很重要的一部分。

关于当当网架构优化的几点心得

第一，对技术部组织架构进行调整。

将原来的职能化组织中的产品、研发和测试部门按照产品线进行整合，转型为Unit化，以加强同一产品线不同职能团队之间的配合协作，沟通更高效，团队更为聚焦。

这样的组织结构更易于应用敏捷，与实施敏捷的前提同理，产品线拆分建立在系统架构解耦基础之上，在这一点上，系统架构与组织架构异曲同工且相辅相成。解耦越充分，系统边界越清晰，模块越小，越适合敏捷团队，能够快速响应业务需求。

业务相近的产品线组成一个产品研发部，这样多数的小型需求在部门内就可以解决，面对紧急项目还可以灵活使用人力资源，并为员工创造接触更多类型业务需求的机会。

第二，系统分层依赖。

随着业务逻辑越来越复杂，系统越来越多，相互依赖也越来越多。比如我的当当中就聚合了安全中心、用户、账户、订单、收藏夹、推荐等多维度的信息，需要调用多个系统服务。经过讨论，决定将用户交互层面的前端页面与原有的后端系统拆分，并入前端的产品线，以便为用户提供更好的服务。

而后端系统之间的依赖关系也需要更为精细的分层定义，对于促销系统，需要会员系统、订单系统、价格系统提供基础数据对于运费系统需要商品信息和配货数据，而在精准定位销售区域的前提下，库存只是配货的基础数据，配货系统负责判断是否有货，Promise则根据配货结果计算预计送达时间。

调整系统之间的关系是很难的，牵一发而动全身，但重构是契机，2015年，对于电商的核心系统交易和促销进行了重构，同时价格、配货、运费等系统也进行了较大调整，从而使系统间依赖问题得到了明显改善。

第三，服务化。

微服务为互联网行业的服务化指明了方向，也坚定了我们进行服务拆分和解耦的决心。

原有的架构以系统为维度，服务归属于明确的系统，而系统的划分一般以业务功能为聚合，随着业务的发展，新的业务功能层出不穷，总会有一些打破原有的系统边界，给架构提出难题。

服务化，不仅是指系统将能力通过服务对外提供，更重要的是服务本身就是承载业务功能的单元，如果有组合了多个逻辑难以归入某系统的服务，不必纠结，作为独立的业务模块开发就是了，以服务为单元，系统架构更加扁平，简单清晰。

微服务架构中，服务粒度会更小，服务治理的需求更加迫切，更需要技术手段解决，比如分布式服务框架，当当使用的是基于Dubbo二次研发的DubboX，以及结合ddframe实现的服务调用监控。

去年的容器技术爆发，为微服务架构实施提供了有力工具，当当内部也在部分系统使用了Docker。

微服务大势所趋，秉承SOA理念，在服务治理中心的基础上，将系统弱化，提供更多的基础服务，提高了系统的复用性和灵活性。

第四，平台化。

平台化包括两个维度，技术平台化和系统平台化。

技术平台化是指在技术层面建立统一的体系，包括根据行业特点进行技术选型，使用稳定可靠的技术组件。

当当从2012年开始将原有的.net平台向Java平台迁移，从封闭到开源，应用电商行业的主流技术栈，到2015年，基本完成了技术转型，主要后端业务系统都转移到Java平台。

经过数年的积累，2015年当当架构部研发了Java应用开发框架ddframe，目的是分离技术和业务，封装技术细节，将应用开发人员的精力集中在业务开发上。

随后再接再厉，当当架构部又推出了用来替代TBSchedule的分布式作业调度框架Elastic-Job。并将之开源，基于JDBC的分布式数据库中间件Sharding-JDBC也在开发中。

统一的技术栈，能够复用技术资源，持续积累整体的研发能力，为做精做专提供更好的基础条件。

系统平台化是指搭建基础平台，包括测试平台、分布式服务平台、自动化运维平台、监控平台、缓存集群、消息中间件平台、大数据处理平台、项目管理系统、日志平台、问题跟踪系统等。

基础平台是各业务系统有机协作的基础，保证了整个技术架构的全面可控，能够降低系统运维复杂度，是大型电商系统不可或缺的组成部分，良好的基础平台是技术实力和管理能力的双重体现，而多数公司更注重业务，会在基础平台建设方面欠下许多技术债务。

2015年，当当搭建了自动化运维平台Pangu、监控平台Radar，重构了项目管理系统，Redis集群管理平台也在搭建中。

第五，核心系统重构。

在电商业务发展的快节奏之下，核心系统持续迭代是常态，而且基本两、三年以上，就需要考虑重构，否则难以支撑业务的快速变化。

另外，系统重构集中梳理业务逻辑和系统依赖，整理统一的文档，剔除无用功能，归并多个版本，甩掉历史包袱重新设计架构，适度的前瞻性设计使系统在一定周期内具备业务扩展性。

2015年，当当完成了交易系统和促销系统进行了重构。

交易系统在2015年10月底完成新老版本切换。重构耗费约1500人天，重构代码17万行，全部切换至Java开源技术架构，为公司节约大量成本，并进行了架构优化，整体性能平均提升25%，经受住了双十一和双十二的考验。

在当当，有一些“类促销”业务，从广义上可以归入促销范畴，但业务与数据均不属于促销系统，在促销系统重构设计中，我们考虑将这类业务逐渐回收另外，促销系统能不能承担一些营销的功能?带着这两点考虑，在促销基础上进一步抽象出活动模型。

你去看你的导航所用的JS有没有与目前网站的JS冲突，如果有冲突的话，肯定不会出来效果。还有就是导航用的CSS是否与网站本身的CSS有冲突（比如一个样式被另一个样式重置等等），再就是检查文件的编码是否一致（有可能你的下拉导航用的是GB2312,而你本身网站用的是UTF8）。

根据上面的方法一一检查就能找到问题出现的原因。

作者：关开发

一.什么是前后端分离？

理解前后端分离大概可以从3个方面理解：

1. 交互形式

2. 代码组织形式

3. 开发模式与流程

1.1 交互形式

前后端不分离

后端将数据和页面组装、渲染好了之后，向浏览器输出最终的html；浏览器接收到后会解析html，解析引入的css、执行js脚本，完成最终的页面展示。

前后端分离

后端只需要和前端约定好接收以及返回的数据格式（一般用JSON格式），向前端提供API接口。前端就可以通过HTTP请求调用API的方式进行交互。前端获取到数据后，进行页面组装、渲染，最终在浏览器呈现。

1.2 代码组织形式

前后端不分离

在web应用早期的时候，前端页面以及后台业务数据处理的代码都放在一个工程下，甚至放在同一目录下，前端页面夹杂着后端代码。前、后端开发工程师都需要把整套代码导入开发工具才能开发。此阶段下前后端代码以及工作耦合度太高，前端不能独立开发和测试，后端人员也要依赖前端完成页面后才能完成开发。最糟糕的情况是前端工程师需要会后端模板技术（jsp），后端工程师还要会点前端技术，需要口头说明页面数据接口，才能配合完成开发。否则前端只能当一个“切图仔”，只输出HTML、CSS、以及很少量与业务逻辑无关的js；然后由后端转化为后端jsp，并且还要写业务的js代码。

前后端分离

前后端代码放在不同的工程下，前端代码可以独立开发，通过mock/easy-mock技术模拟后端API服务可以独立运行、测试；后端代码也可以独立开发，运行、测试，通过swagger技术能自动生成API文档供前端阅读，还可以进行自动化接口测试，保证API的可用性，降低集成风险。

1.3 开发模式与流程

前后端不分离

在项目开发阶段，前端根据原型和UI设计稿，编写HTML、CSS以及少量与业务无关的js（纯效果那些），完成后交给后台人员，后台人员将HTML转为jsp，并通过JSP的模板语法进行数据绑定以及一些逻辑操作。后台完成后，将全部代码打包，包含前端代码、后端代码打成一个war，然后部署到同一台服务器运行。顶多做一下动静分离，也就是把图片、css、js分开部署到nginx。

具体开发流程如下：图略

前后端分离

实现前后端分离之后，前端根据原型和UI设计稿编写HTML、CSS以及少量与业务无关的js（纯效果那些），后端也同时根据原型进行API设计，并与前端协定API数据规范。等到后台API完成，或仅仅是API数据规范设定完成之后。前端即可通过HTTP调用API，或通过mock数据完成数据组装以及业务逻辑编写。前后端可以并行，或者前端先行于后端开发了。

具体开发流程如下：图略

二、前后端分离的好处与坏处。

从上面3个方面对比了之后，前后端分离架构和传统的web架构相比，有很大的变化，看起来好处多多。到底是分还是不分，我们还是要理性分析是否值得才去做。

从目前应用软件开发的发展趋势来看，主要有两方面需要注意：

· 越来越注重用户体验，随着互联网的发展，开始多终端化。

· 大型应用架构模式正在向云化、微服务化发展。

我们主要通过前后端分离架构，为我们带来以下四个方面的提升：

· 为优质产品打造精益团队

通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。

· 提升开发效率

前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。

· 完美应对复杂多变的前端需求

如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。

· 增强代码可维护性

前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。

那么前后端分离有什么不好的地方吗？我目前是没有想到，除非你说会增加前端团队的配备，后端工程师会变的不全能。。。

二、前后端分离架构方案。

实现前后端分离，主要是前端的技术架构变化较大，后端主要变为restfull 风格API，然后加上Swagger技术自动生成在线接口文档就差不多了。

对于目前用于前后端分离方案的前端技术架构主要有两种：

· 传统SPA

· 服务端渲染SSR

2.1 传统SPA

传统SPA指的是单页面应用，也就是整个网站只有一个页面，所有功能都通过这一个页面来呈现。因为一个人的肉眼，某一个时间点看一个页面，既然如此何必要不同功能做多个页面呢？只保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容不就可以了吗？确实如此，现在通过reac全家桶、tvue全家桶，模块化、路由、wabpack等技术轻而易举就能实现一个单页面应用。

单页面应用的运行流程

1.用户通过浏览器访问网站url

2.单页面的html文件（index.html）被下载到浏览器，接着下载html里面引用的css，js。

3.css，js下载到浏览器完成之后，浏览器开始解析执行js向后端服务异步请求数据。

4.请求数据完成后，进行数据绑定、渲染，最终在用户浏览器呈现完整的页面。

2.2 服务端渲染

服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的html。大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是NodeJs服务端。

它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。浏览器请求前端页面时，会先经过NodeJS服务端，由NodeJs去读取前端页面，并执行异步后端API，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的html然后返回浏览器，最后浏览器进行展示。

服务端渲染应用的运行流程：

1.用户通过浏览器访问网站url

2.NodeJS服务端接收到请求，读取到对应的前端html，css，js。

3.NodeJS解析执行js向后端API异步请求数据。

4.NodeJs请求数据完成之后，进行数据绑定、渲染，得到一个最终的html。

5.NodeJs向浏览器输出html，浏览器进行展示。

PS：其实本质就是把前端编写成一个nodeJs的服务端web应用。实施服务端渲染后，我们最终运行的是一个Nodejs服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。

看到这里，你是否又有疑问，为什么要这么麻烦搞服务端渲染呢？

2.3 SPA与服务端渲染方案对比

SPA的优点是开发简单，部署简单；缺点是首次加载较慢，需要较好的网络，不友好的SEO。

so，以下就是使用服务端渲染的理由了（摘取vue官方说法）：

与传统 SPA (单页应用程序 (Single-Page Application)) 相比，服务器端渲染 (SSR) 的优势主要在于：

· 更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。

请注意，截至目前，Google 和 Bing 可以很好对同步 JavaScript 应用程序进行索引。在这里，同步是关键。如果你的应用程序初始展示 loading 菊花图，然后通过 Ajax 获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 SEO 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。

· 更快的内容到达时间 (time-to-content)，特别是对于缓慢的网络情况或运行缓慢的设备。

无需等待所有的 JavaScript 都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验，并且对于那些「内容到达时间(time-to-content) 与转化率直接相关」的应用程序而言，服务器端渲染 (SSR) 至关重要。

使用服务器端渲染 (SSR) 时还需要有一些权衡之处：

· 开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；一些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行。

· 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。

· 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic) 下使用，请准备相应的服务器负载，并明智地采用缓存策略。

以vue为例，实施服务端渲染可以查看官方指南： https://ssr.vuejs.org ，或选择Nuxt.js

2.4 预渲染技术

如果你调研服务器端渲染 (SSR) 只是用来改善少数营销页面（例如 /, /about, /contact 等）的 SEO，那么你可能需要预渲染。无需使用 web 服务器实时动态编译 HTML，而是使用预渲染方式，在构建时 (build time) 简单地生成针对特定路由的静态 HTML 文件。优点是设置预渲染更简单，并可以将你的前端作为一个完全静态的站点。

如果你使用 webpack，你可以使用 prerender-spa-plugin 轻松地添加预渲染。它已经被 Vue 应用程序广泛测试 - 事实上，作者是 Vue 核心团队的成员。

prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin

三、前后端分离技术选型

- artTemplate + bootstrap（不推荐， 不算完全前后端分离）

- vue全家桶（推荐）

- react全家桶 （推荐，生态全）

---