seo淘宝网网站架构图(淘宝网的业务系统)
seo淘宝网网站架构图
从工程的角度看，搜索和推荐既有差异点，又有共同点。阿里巴巴集团的搜索和推荐系统由同一个部门研发，因此很多工程能力是复用的，如搜索和推荐业务的算分服务引擎都是RS/RTP。
本文介绍阿里巴巴推荐的中台产品—BE召回引擎和RTP算分服务，这是阿里巴巴推荐业务的两项利器。
召回引擎BE
BE（Basic Engine）是基于阿里巴巴集团另一个更底层的框架服务Suez构建的。在Suez框架服务的基础上，BE实现了与推荐业务相关的各种功能组件，如向量召回技术、多表join召回，以及以自定义插件形式提供的排序和算分插件接口。
1.架构及工作原理
BE是一个典型的多列searcher+proxy架构，如图1所示。
图1 BE集群部署
图1中的proxy集群有3个实例，完全对等，互为备份。searcher集群有2行4列，这表示I2I等数据被划分成4份放到4列机器上。每一列上的数据各不相同，但是执行的计算逻辑完全相同，4列合在一起组成完整的一行。2行之间完全对等，互为备份。
各种I2I/S2I/B2I的召回（search）、合并（union）、关联（join）、过滤（filter）和排序（sorter）均在searcher本地完成，最后经过proxy的合并排序（merge sorter）返回，如图2所示。
图2 BE内部逻辑
图2中的I2I、S2I、C2I都是BE支持的召回功能，BE底层是基于阿里巴巴搜索事业部研发的通用索引和检索模块indexlib实现的，这里主要用到了indexlib的KV和KKV检索的功能。
顾名思义，KV检索是输入一个或者多个K，返回一个或者多个V。KKV检索是输入pkey和skey，返回单个值；如果只输入pkey，不输入skey，则返回的是值序列。在实际的推荐业务中，主要就是用这两种检索召回机制。
合并功能（union）：指的是对多张表的检索结果进行合并，取并集，并记录召回的来源表的信息和是否被两张表同时召回的信息。这些召回过程中记录下来的信息可以用在算分阶段，比如不同的来源表权重不同，则最终得分不同；以及如果是两张表同时召回的，说明被召回的元素命中多种召回策略，则两张来源表的权重相加作为最终权重用于算分，得分就更高了。
关联功能（join）：由于左表所存储的信息有限，从左表召回元素集合之后，还有一些信息存在右表，通过join功能可以获取右表的信息，让记录的字段更丰富。该功能用于算分阶段和返回给调用方。
排序功能（sorter）：按某个字段或者表达式进行排序，支持用自定义插件实现。
最后，对不同的列（partition）的结果进行合并，然后返回给调用方，这是一个完整的BE召回过程。
2、BE向量召回和应用
时下有一种非常流行的召回机制叫作向量召回，它通过将元素（实体）进行向量化表征来构建便于高效检索的索引。在检索端，也用相同的方式对检索元素（实体）进行向量化处理，利用检索技术进行检索召回，得到距离相近的商品或者元素（实体）集合，并根据距离远近进行排序。
实际上，这里用到的底层向量索引和检索技术是由阿里巴巴达摩院研发的，一方面将其封装成通用的底层功能库，集成到BE服务中，用于词向量和短文本向量召回的场景；一方面将其集成到其他服务（如HA3引擎）中，用于在文本搜索场景下解决文本匹配不足而造成的零少结果问题。
在BE中，向量召回也是一种召回方式，可以与BE最擅长的KV和KKV召回形式同时使用，也可以作为一种独立的召回方式实现完整的业务召回。
目前，向量召回已在阿里巴巴集团的大量场景（如猜你喜欢、猫客、SEO等场景）中应用，并取得了不错的效果。在1688的业务实践中，我们用BE的向量召回功能实现了SEO内链系统的重构，取得了不错的业务结果。
SEO（Search Engine Optimization，搜索引擎优化）是一种重要的营销手段，商家通过影响用户搜索引擎内的自然排名从搜索引擎中获得尽可能多的免费流量。SEO流程为：发现→抓取→解析→索引→排名→展现→转化。其中，内链系统就占了其中的3个重要环节：通过构建内链系统扩大搜索发现率、提高网页爬虫抓取量。因此，优化SEO内链系统对于SEO站内优化非常重要。
http://1688.com之前的SEO内链系统存在覆盖率不高且不均匀、相关性不佳、零少结果较多的问题。使用BE的向量召回功能重构SEO内链系统后，完美地解决了以上问题，召回成功率、覆盖率、相关性均有大幅提升。从整体效果看，爬虫量和索引量指标均得到大幅提升。
http://1688.com的SEO系统的架构如图3所示。
图3 1688的SEO系统架构
BE是推荐系统负责在线召回的引擎，基于DII算法在线服务平台实现，融合了搜索从离线到在线的全链路技术体系，并依托管控系统，实现了从开发、上线到运维的全生命周期管理。
从逻辑上讲，BE主要负责从多种类型的索引表中召回商品，并根据对应的商品信息进行过滤和粗排。其中filter和sorter是算法插件，可以灵活配置在检索流程的各个环节，具体的过滤和排序逻辑由算法工程师根据业务场景进行编写。同时，BE也内置了大量的通用组件。在灵活性和可扩展性方面，BE具备一个中台产品支持多种推荐业务的能力。
算分服务RTP
为满足推荐和搜索两大业务对score/rank的需求，阿里巴巴搜索事业部在2016年开发了最初的RTP系统Rank Service排序服务器。它是一个支持数据分区、function函数插件化、实时feature特征和model模型更新的分布式服务。基于Rank Service我们可以搜索业务的match匹配和rank排序拆分为两个独立的模块，从而提升业务迭代效率及整体集群性能。
为更好地支持算法团队快速迭代深度模型，赋能业务，搜索事业部又对RTP系统进行了大幅度的迭代和升级。2017年引入了TensorFlow，将整个RTP框架改造成一个图执行引擎，从而可以支持任意的可用图描述的机器学习模型。在此基础上，又进一步增加了按模型分partition的功能，从而解决了超大模型单机无法容纳的问题。
在阿里巴巴内部，推荐业务使用了RTP的在线打分功能；搜索业务不仅使用了在线打分功能，还使用RTP对打分的结果进行在线排序。
1. RTP和TensorFlow Serving
TensorFlow在2017年提供了Tensorflow Serving，可以将训练好的模型直接上线并提供服务，RTP也支持将TensorFlow的模型上线并提供服务。那么，问题来了，既然已有TensorFlow Serving，为什么还要用RTP？引用RTP开发团队资深技术专家以琛的观点，相比TensorFlow Serving，RTP有如下3方面特点和优势。
对于大规模打分场景而言，大部分的数据从请求中带入是不合适的，而RTP系统本地有数据存储的能力，而且是基于Suez框架的表存储，有高效的压缩读取机制，同时还能完全支持实时链路。
RTP系统额外增加的feature产生、数据读取、插件等机制，使其能够做到灵活支撑业务逻辑。
RTP系统是基于Suez框架开发的，因此能继承其管控系统、分布式行列服务等能力，这使得我们的系统拥有了数据分片、模型分片的能力，从而在大规模模型或者数据应用场景中，发挥巨大优势。
Suez在线服务框架是搜索事业部自研的大数据在线服务的通用抽象（要求具备秒级数据更新的最终一致性）。Suez框架统一了以下3个维度的工作。
索引存储（全文检索、图检索、深度学习模型）
索引管理（全量、增量及实时更新）
服务管理（最终一致性、切流降级扩缩容等）
下面用一张图来描述RTP与Suez框架的关系。
图4是RTP系统的架构图。图中Tf_search是RTP的内核，基于Indexlib和Suez Worker承载对外提供端口服务。Suez Worker的部署由Suez admin完成和管理，而Suez worker和Suez admin的机器资源（如CPU、内存等）都是通过一个叫作Hippo的资源调度框架来管理的。
图4 RTP系统架构
RTP和TensorFlow Serving一样，基本的功能就是将模型进行加载并提供端口对外服务。下面，首先从阿里巴巴网站的搜索和推荐业务来阐述RTP在其中的位置；然后，介绍RTP的模型和数据更新机制；
接着，从RTP提供对外服务接口开始，一步步深挖RTP是如何借鉴TensorFlow的图化思想来实现既支持TensorFlow的原生深度模型，又支持LR模型、GBDT等传统模型的；最后，介绍在面对海量的数据和模型时，RTP在工作效率、稳定性及性能方面具备的独特优势。
2. RTP在阿里巴巴的应用
RTP应用在阿里巴巴的搜索和推荐业务中。对于搜索业务，RTP不仅用于对商品集合进行在线打分，也用于对商品集合按规则进行排序。对于推荐业务，RTP主要用于对商品集合批量打分。
图5是从搜索架构的视角看RTP的位置和作用。Rank Service和RTP内部其实是基于同一份二进制文件拉起的服务，都可以认为是宽泛意义上的RTP。两者的差异在于加载的模型不同，因而作用不同。
图中左下角的Rank Service加载的是Hobbit和Unicorn的Graph，作用是打分和排序；图中右下角的RTP加载的是深度模型的Graph，如WDL模型，作用是打分。
Rank Service将商品集合信息请求RTP，RTP算分后将结果返回给Rank Service，然后按分值进行排序，这些都是在Hobbit和Unicorn的Graph中完成的。
图5 RTP架构角色
我们接下来再从推荐架构的视角看RTP的位置和作用。推荐架构相对简洁，基于RTP使用模型对商品集合进行在线打分。
在阿里巴巴，ABFS（Ali Basic Feature Service）提供的是用户实时行为特征服务。IGraph既可以提供商品维度的信息，也可以提供用户行为的信息，是一个非常重要的图存储引擎，而BE则是推荐召回引擎。
图6中的TPP是将上述在线服务编排、处理、整合的一个平台。首先，TPP使用买家ID请求ABFS和IGraph，获取用户实时行为和离线行为特征；然后，将这些行为作为条件去请求BE，进行商品集合的召回；
最后，将商品集合、商品特征、用户特征一起请求RTP，对商品进行打分。在打分完成后，还会在TPP内部进行排序及翻页处理，然后再传出给调用方。
图6 推荐系统架构
上述典型的搜索和推荐业务是对批量的商品进行打分或者排序，除此之外，RTP还承接了其他类似的推荐业务，如对榜单、直播、短视频等进行打分。另外，RTP还承接了打分和排序以外的模型服务，例如1688的智能文案在线生成服务。
3. RTP模型和数据更新
原生的TensorFlow模型（如saved model）是不区分模型和数据的，只有模型的概念。这里的模型实际包含了两类信息：一类是图的结构，一类是参数的权重数据。在一个目录下存了多个文件，共同存储上述两类信息。RTP也支持saved model格式，不过这并不是RTP在生产环境的主流使用方式。
在生产环境的主流使用方式中，RTP出于对性能和数据容量的考虑，会将TensorFlow的原生模型按RTP的格式要求进行转换，分成两部分：一部分是抽取和转成网络结构，可以认为是模型的元数据，采用GRAPH.def的文件存放和使用；
另一部分是参数和对应的权重信息，采用KV表的形式进行分发和使用。RTP借助Suez框架将上述两部分信息进行分发并加载到内存中。上述网络结构的更新是非实时的，可以做到小时级别的更新，而参数和对应的权重支持实时更新，已应用在2019年的天猫“双11”大促中。
另外，RTP还有一部分信息可以做到实时更新，这就是内容表（item table）。在主流的应用场景中，内容表是一个超级大表，也是一个KV表，Key是商品ID，Value是商品维度的原始特征。
这么做是为了减小从请求串中传递的参数大小。大部分商品维度的特征可以从服务器本地的KV表中读取，而不是从请求串中解析。试想一下，如果数千个商品维度的特征都从请求串中传递，这个请求串会非常大，仅解析请求串、反序列化对象就会消耗不少时间。
4. RTP对外接口服务
一个系统想在竞争对手如林的环境中生存下来并推广开去，不断提升系统的用户体验很重要。在不同的业务场景和开发场景中，不同的使用者会要求不同的调用方式。RTP的对外接口支持用多种请求调用的方式来满足多种场景的需求，如图7所示。
图7 RTP请求模式
RTP支持基于HTTP和ARPC两种协议的请求方式。其中，基于HTTP协议的请求方式与其他平台差别不大，整体过程就是在HTTP客户端将所有的输入拼装成JSON对象，按POST协议进行请求；
然后在RTP服务端将JSON对象解析为tensor input张量输入和tensor fetch张量读片以及其他的相关信息，调用TensorFlow Graph的执行器运行模型，得到fetch读片的具体内容；最后用同样的方式封装成JSON对象并返回给客户端。
对于基于ARPC协议的请求方式，其支持两种请求对象：一种是PBRequest，也就是JSON对象封装成了PB对象，其优点是对于单个请求附带了大量的商品id集合的场景，有比较大的性能提升；
一种是GraphRequest，这种请求是通过RTP客户端的SDK封装好tensor的input、fetch以及其他信息，存储到GraphRequest对象中，通过ARPC调用RTP，在RTP协议转换层将这些tensor信息传递给Tensor-Flow图执行器运行模型，得到输出的fetch的tensor。
基于HTTP协议的请求格式主要用于开发过程中的调试，在生产环境中会使用基于ARPC协议的请求格式。
5. RTP内部实现原理
前面讲到，RTP将模型拆分成两部分：一部分是纯粹的图结构，一部分是参数和权重数据。RTP会对图进行转化，将Training Graph训练图转成Inference Graph推理图，并对某些节点进行替换改写，使之能够读取本地数据KV表。图8所示是对训练出来的模型图进行添加和裁剪的过程。
图8 模型加载
添加一些节点，如Placeholder，用于外部请求数据的输入；也会添加一些Feature Generator特征生成器相关的节点，用于对请求串中输入的数据进行特征生成。
这些特征生成节点如果涉及商品维度的特征生成，往往会和本地的内容表关联，在节点执行时，会检索本地内容表，获取商品维度的数据，然后进行特征生成。另外，会对某些节点（如Loss节点）进行删除，因为前向预测时，这些节点是用不上的。
RTP在阿里巴巴集团的搜索和推荐体系中占据了非常重要的位置，工程实现的管控系统对训练和上线流程的封装让整个过程非常顺畅，让算法工程师能专注于模型的优化，从而大大提高算法的生产效率。
RTP基于图化的内核设计思想，支持将各种原生的算法模型都转成图化模型的形式，具备极强的通用性，这也是RTP在集团内部如此受欢迎的原因之一。同时，RTP结合Suez框架提供的本地数据存储和查询机定制开发了一些图化操作算子，提升了模型预测的计算性能。
RTP服务端具备分布式存储数据和分片部署的能力，让数以亿计的商品维度的数据不再通过网络传输，减少了网络传输，极大提升了模型执行的性能。RTP依托Suez框架实现了模型和数据的实时更新能力，让模型能快速捕捉当前的变化，提升准确性。
本文摘编于《阿里巴巴B2B电商算法实战》经出版方授权发布。
#欢迎来留言#
你用过BE召回引擎和RTP算分服务吗？
对此你怎么看？
CSDN携手【机械工业出版社】送出
《阿里巴巴B2B电商算法实战》一本
截至7月30日12:00点
简介：本书是阿里巴巴CBU技术部（ http://1688.com）深耕B2B电商15年的经验总结。阿里巴巴B2B在战略形态上经历了信息平台、交易平台和营销平台的升级迭代，本书聚焦营销平台商业形态背后的算法和技术能力，试图从技术和商业互为驱动的视角阐述技术如何赋能业务，并结合阿里巴巴集团在基础设域和算法创新上的沉淀，打造出智能B2B商业操作系统。
淘宝网的业务系统
7月14日晚间，据媒体报道，阿里和腾讯考虑相互开放生态系统，双方都在分别制定放松限制计划。阿里的初步举措可能包括将腾讯的微信支付引入淘宝和天猫；而腾讯可能将允许阿里的电商信息在微信上分享。目前，腾讯和阿里尚未对此事进行回应。
此前，微信与淘宝关系已出现缓和迹象，今年4月，继淘宝特价版之后，闲鱼也向微信提交了小程序申请，目前申请仍在审批中，随着双方相互开放生态系统，审批申请或将加速落地。
一直以来，互联网市场激烈竞争“封杀”、“站队”现象屡见不鲜，而腾讯和阿里这两大阵营也曾发生多次相互屏蔽对抗竞争。2013年11月22日，淘宝以“微信不安全”的理由封杀微信，微信用户无法在微信内点击任何淘宝链接，会被自动导向淘宝APP的下载页。2015年2月，继支付宝红包开通微信、QQ入口8个多小时后被微信封杀。不少商家反映，通过微信平台开设的店铺无法使用支付宝收付款。
不光在业务上的拼杀较量，就连双方大佬“二马”的口水战也是赚足了眼球。2017年9月8日马化腾在论坛上暗怼马云称，大街小巷有很多微信支付，但我们其实并不排斥别人（支付宝），反之就不是这样了。同年9月，马云曾在接受采访时对于“二马”在海外市场的竞争表示“到其他国家做生意，马化腾也不见得比我们强”。
两家明里暗里较量竞争了这么多年为何此时选择握手言和？此次，双方握手言和或是为配合国家反垄断政策的落地。
今年，7月8日监管部门对互联网行业 22 起违法实施经营者集中案件开出罚单，违反了《中华人民共和国反垄断法》第二十一条，构成违法实施经营者集中，市场监管总局根据《中华人民共和国反垄断法》第四十八条、四十九条作出行政处罚决定，对涉案企业分别处以 50 万元人民币罚款。其中涉及阿里巴巴 6 起，罚款额达300万元，涉及腾讯 5 起，罚款额达250万元。
今年4月10日，国家市监局依法对阿里巴巴集团实施“二选一”垄断行为作出182.28亿元行政处罚，是中国反垄断法实施以来开出最大的罚单。随着政策的收紧，反垄断监管将会常态化。
其实，腾讯和阿里曾经在音乐版权上就曾“牵手”。2015年，在线音乐版权大战愈演愈烈，国家版权局几度出手调解，2017年9月阿里音乐和腾讯音乐版权互授，2018年2月腾讯音乐和网易云音乐版权互授，至此，在线音乐三大巨头版权曲库打通，在线音乐版权之争告一段落。
此次，阿里腾讯互相开放生态系统，不失为一种双赢。阿里电商可以通过腾讯微信强大社交基因实现导流，而腾讯微信支付引入淘宝和天猫，也可以在金融业务上进一步突破。截至目前，阿里港股上涨3.1%，腾讯港股上涨1.98%。
“分久必合”正成为互联网巨头之间暗中较量的一种趋势，对巨头而言，各自为营到合作共赢正在成为一种趋势，对用户而言，相互开放的互联网生态环境下也有更多的机会与选择。
seo淘宝网网站架构图
若汐缘
https://www.jianshu.com/p/796f488fd134
前言
以淘宝网为例，简单了解一下大型电商的服务端架构是怎样的。如图所示最上面的就是安全体系系统，中间的就是业务运营系统，包含各个不同的业务服务，下面是一些共享服务，然后还有一些中间件，其中 ECS 就是云服务器，MQS 是队列服务，OCS 是缓存等等，右侧是一些支撑体系服务。
除图中所示之外还包含一些我们看不到的，比如高可用的体现。淘宝目前已经实现多机房容灾和异地机房单元化部署，为淘宝的业务也提供了稳定、高效和易于维护的基础架构支撑。
这是一个含金量非常高的架构，也是一个非常复杂而庞大的架构，当然这个架构不是一天两天演进成这样的，也不是一开始就设计并开发成这样的，对于初创公司而言，很难在初期就预估到未来流量千倍、万倍的网站架构会是怎样的状况，同时如果初期就设计成千万级并发的流量架构，也很难去支撑这个成本。
因此一个大型服务系统，都是从小一步一步走过来的，在每个阶段找到对应该阶段网站架构所面临的问题，然后不断解决这些问题，在这个过程中，整个架构会一直演进，同时内含的代码也就会演进，大到架构、小到代码都是在不断演进和优化的。所以说高大上的项目技术架构和开发设计实现不是一蹴而就的，这是所谓的万丈高楼平地起。
单机架构
从一个小网站说起，一般来说初始一台服务器就够了，文件服务器、数据库以及应用都部署在一台机器上。也就是俗称的 allinone 架构。
多机部署
随着网站用户逐渐增多，访问量越来越大，硬盘、cpu、内存等开始吃紧，一台服务器难以支撑。看一下演进过程，我们将数据服务和应用服务进行分离，给应用服务器配置更好的 cpu、内存等等，而给数据服务器配置更好、更快的大的硬盘，如图所示用了三台服务器进行部署，能提高一定的性能和可用性。
分布式缓存
随着访问的并发越来越高，为了降低接口的访问时间提高服务性能，继续对架构进行演进。
我们发现有很多业务数据不需要每次都从数据库中获取，于是我们使用了缓存，因为 80% 的业务访问都集中在 20% 的数据上 (二八原则)，如果能将这部分数据缓存下来，性能就能提高很多，缓存又分两种，一种是 Application 中的本地缓存，还有远程缓存，远程缓存又分为远程的单机式缓存和分布式缓存 (图所示的是分布式缓存集群)。
我们需要思考几点，具有哪种业务特点的数据使用缓存，具有哪种业务特点的数据使用本地缓存，具有哪种业务特点的数据使用远程缓存。分布式缓存在扩容时会遇上什么问题，如何解决，分布式缓存的算法都有哪几种，都有什么优缺点。这些问题都是我们在使用这个架构时需要思考并解决的问题。
服务器集群
这个时候随着访问的 qps 不断提高，假设我们使用的 Application Server 是 tomcat，那么 tomcat 服务器的处理能力就会成为一个瓶颈，虽然我们也可以通过购买更强大的硬件但总会有上限，并且这个成本到后期是呈指数级的增长。
这时候就可以对服务器做一个集群 (cluster)，然后添加负载均衡调度器 (LoadBalancer)，服务器集群后我们就可以横向扩展我们的服务器了，解决了服务器处理能力的瓶颈。
此时我们又需要思考几个问题， 负载均衡的调度策略都有哪些，各有什么优缺点，各适合什么场景，比如轮询、权重、地址散列，地址散列又分为原 IP 地址散列、目标 IP 地址散列、最小连接、加权最小连接等等。
服务器集群后，假设我们登陆了 A 服务器，session 信息存放在 A 服务器上了，如果我们的负载均衡策略是轮询或者最小连接等，下次是有可能访问到 B 服务器，这时候存储在 A 服务器上的 session 信息我们在 B 服务器是读取不到的，所以我们需要解决 session 管理的问题。
Session 共享解决方案
session sticky
我们使用 session sticky这种方式来解决这个问题，它的处理规则是对于同一个连接中的数据包，负载均衡会将其进行 NAT 转换后，转发至后端固定的服务器进行处理，这种方案解决了 session 共享的问题。
如图所示客户端 1 通过负载均衡会固定转发到服务器 1 中。缺点是第一假设有一台服务器重启了，那么该服务器的 session 将全部消失，第二是我们的负载均衡服务器成了一种有状态的服务器，要实现容灾会有麻烦。
session 复制
session 复制，即当 browser1 经过负载均衡服务器把 session 存到 application1 中，会同时把 session 复制到 application2 中，所以多台服务器都保存着相同的 session 信息。
缺点是应用服务器的带宽问题，服务器之间要不断同步 session 信息，当大量用户在线时，服务器占用内存会过多，不适合大规则集群，适合机器不多情况。
基于 cookie
基于 cookie，也就是说我们每次都用携带 session 信息的 cookie 去访问应用服务器。缺点是 cookie 的长度是有限制的，cookie 保存在浏览器上安全性也是一个问题。
session 服务器
把 session 做成了一个 session 服务器，比如可以使用 redis 实现。这样每个用户访问到应用服务器，其 session 信息最终都存到 session server 中，应用服务器也是从 session server 中去获取 session。
要考虑以下几个问题，在当前架构中 session server 是一个单点的，如何解决单点，保证它的可用性，当然也可以将 session server 做成一个集群，这种方式适用于 session 数量及 web 服务器数量大的情况，同时改成这种架构后，在写应用时，也要调整存储 session 的业务逻辑。
数据库读写分离
在解决了服务器横向扩展之后，继续看数据库，数据库的读与写操作都需要经过数据库，当用户量达到一定量时，数据库性能又成为了一个瓶颈，我们继续演进。
我们可以使用数据库的读写分离，同时应用要接入多数据源。通过统一的数据访问模型进行访问。数据库的读写分离是将所有的写操作引入到主库中 (master)，将读操作引入到从库中 (slave)，此时应用程序也要做出相应的变化，我们实现了一个数据访问模块 (data accessmodule)，使上层写代码的人不知道读写分离的存在，这样多数据源的读写对业务代码就没有侵入，这就是代码层面的演变。
如何支持多数据源，如何封装对业务没有侵入，如何使用目前业务使用的 ORM 框架完成主从的读写分离，是否需要更换 ORM，各有什么优缺点，如何取舍都是当前这个架构需要考虑的问题。当访问量过大时候，也就是说数据库的 IO 非常大，我们的数据库读写分离又会遇到以下问题？
例如主库和从库复制有没有延迟，如果我们将主库和从库分机房部署的话，跨机房传输同步数据更是一个问题。另外应用对数据源的路由问题，这些也是需要思考和解决的点。
CDN 加速与反向代理
我们继续增加了 CDN和反向代理服务器 (Reverseproxy server)，使用 CDN可以很好的解决不同地区访问速度问题，反向代理则在服务器机房中可以缓存用户的资源。
分布式文件服务器
这个时候我们的文件服务器又出现了瓶颈，我们将文件服务器改成了分布式文件服务器集群，在使用分布式文件系统时，需要考虑几个问题，如何不影响部署在线上的应用访问，是否需要业务部门帮忙清洗数据，是否需要备份服务器，是否需要重新做域名解析等等。
数据库分库分表
这个时候我们的数据库又出现了瓶颈，我们选择专库专用的形式，进行数据的垂直拆分，相关的业务独用自己的一个库，我们解决了写数据并发量大的问题。
当我们把这些表分成不同的库，又会带来一些新的问题。例如跨业务和跨库的事务，可以使用分布式事务，或者去掉事务，或者不追求强事务。
随着访问量过大，数据量过大，某个业务的数据库数据量和更新量已经达到了单个数据库的瓶颈了，这个时候就需要进行数据库的水平拆分，例如把 user 拆分成了 user1 和 user2，就是将同一个表的数据拆分到两个数据库当中，这个时候我们解决了单数据库的瓶颈。
水平拆分时候又要注意哪些点，都有哪几种水平拆分的方式。进行了水平拆分后，又会遇到几个问题，第一 sql 路由的问题，假设有一个用户，我们如何知道这个用户信息是存在了 user1 还是 user2 数据库中，由于分库了，我们的主键策略也会有所不同，同时会面临分页的问题，假设我们要查询某月份已经下单的用户明细，而这些用户又分布在 user1 和 user2 库中，我们后台运营管理系统对它进行展示的时候还要进行分页。这些都是我们在使用这个架构时需要解决的问题。
搜索引擎与 NoSQL
在网站发布并进行了大规模的推广后，导致我们应用服务器的搜索量又飙升，我们把应用服务器的搜索功能单独抽取出来做了一个搜索引擎，同时部分场景可以使用 NoSQL来提高性能。同时我们开发一个数据统一的访问模块，同时连着数据库集群、搜索引擎和 NoSQL，解决上层应用开发的数据源问题。
后序
这里只是简单举例，并没有依据什么实际的业务场景。事实上各个服务的架构是要根据实际的业务特点进行优化和演进的，所以这个过程也不是完全相同的。当然这个架构也不是最终形态，还存在很多要提升的地方。
例如负载均衡服务器目前是一个单点的，如果负载均衡服务器访问不了，那么后续的包括服务器集群等也就无法访问了。所以可以将负载均衡服务器做成集群，然后做一些主从的双机热备，同时做一个自动切换的解决方案。
在整个架构的演进过程中，其实还包含更多需要关注的内容，比如安全性、数据分析、监控、反作弊......针对一些特定的场景例如交易、充值、流计算等使用消息队列、任务调度......整个架构继续发展下去，做成 SOA 架构、服务化 (微服务)、多机房......
最后，我想说高大上的项目技术架构和开发设计实现绝不是一僦而就的。
淘宝网的业务系统
生活中，我们熟悉的电商平台莫过于淘宝了，而淘宝作为一个典型代表，它的评价系统也很值得研究。
交易的最原始状态是等价交换，互联网场景下的交易孕育了电商，如何保证等价交换是电商要解决的根本，表现在消费者与商家的关系上就是信任，这便是电商的基石。
评价系统是信任体系的重要一环，它将商品、商家、消费者、平台联系了起来，各方对于评价系统的需求也不相同，笔者认为宏观上离不开这几点：
很明显，商家和消费者处于对立位置，平台作为规范市场和促成交易的中间角色，为了设计出优秀的评价系统可谓煞费苦心。淘宝作为最早的电商平台之一，对业务逻辑的处理也最为完善，在维护买卖双方利益的条件下满足各方对评价的诉求。本文对淘宝平台做如下的竞品分析，文章结构如下:
一、评价流程分析
评价流程可能同时涉及用户、商家、平台，评价流程越完善，必定增加用户停留时间，于买家有利，可以从多维度了解商品；但也可能增加纠纷与平台维护难度，于商家可能不利。对于某些供给端（商家）相对缺乏的平台而言选择更精简的评价流程。如下是淘宝平台评价流程：
其中，在用户确认收货申请售后退款成功后仍可进行评价的功能持保留意见，在这方面，京东的处理做法是退款成功后相应评价也随之删除，且删除评价只有这种方式。删除评价机制的难易程度同时也直接影响到评价内容的真实性，相较而言，京东商家维护评价的意愿并不强烈。
二、评价系统功能需求分析
淘宝为用户提供的评价形式有买家相册、宝贝评价、问大家、动态评分为主要架构的评价体系，笔者从产品功能现状入手，从用户、商家、平台角度倒推系统所提供的功能想要解决的需求。
1. 买家相册
用户需求出发点：点开评价才能看到商品实拍图片，懒于操作。
商家需求出发点：希望挑选有利于提高转化率的优质图片给买家。
买家相册位于产品主页中部位置，主页展现形式为单纯图片，点击后展示形式为图片+部分评语。就实际效果而言，商家可后台挑选优质图片到展示集合中，确实是良心之作；对于买家，提升了购物体验。
2. 宝贝评价
宝贝评价位于产品主页中部，买家相册之上，主页外观上只透出一条评价文字内容，4个标签，并标注所有评价数。查看全部内容后显示信息最为丰富，展现形式为图片+视频+文字，其中整体包括的功能模块、功能需求如下图：
首先，可以吐槽下折叠功能，这个折叠功能的最原始需求由来于评论规则，当买家15天内未评价将自动默认好评，而默认好评是空白却还要显示，因为之后可能买家会追评，于是折叠功能就是为了折叠这部分内容。而其实更为本质的需求是解决评论内容的同质化问题，如今商家操纵评价现象严重，评价清一色200字以上，其实内容都是“产品很好，物流很快，客服态度好”这种空洞的文字。与小红书的种草笔记相比，内容质量有些差距。
其次，评价规则的过多会给别有用心之人不当利用，如中、差评延时生效及鸡肋的匿名功能导致很多商家为避免负面评价过度骚扰买家用户，投诉漏洞催生一大批以删除评价为名的利益链。天猫商城取消好中差评功能从一定程度提高了商品准入门槛，为商品质量提供初步保证。值得一提的是淘宝的动态评价排序算法：评价时间、内容优质程度、图片数量、文字数量、是否有视频、点赞数、会员等级等，均可能影响评价排序。
3. 问大家
问大家模块可以说填补了宝贝评价部分的短板，评价部分单向传播属性较强，而问大家功能搭起了已购买与未购买用户之间的桥梁，其不支持删除及随机邀请的机制最大程度保证了用户获取信息的真实性。这部分的具体功能需求如下表：
4. 动态评分
动态评分内容为描述+服务+物流，提交后不可更改，而且商家和用户都无法查看个体的记录。
用户需求出发点：做出购买决策时希望直观地了解以往买家对店家、商品的满意度。
三、改进意见
为保证评价的真实性，并给予未购买用户确切的决策建议。需要产品经理构建有效评价模型，配合数据分析师和研发共同建模。
星级评分本来就是一种模棱两可的评价方式，4分与5分可能相差并不多，系统也无法探知用户真正的喜好，点赞与踩一下的简单评价方式某种程度上能更直观地反映用户满意度。评价高低可能与个体主观感受息息相关。
电商平台评分算法有很大改进空间，目前现在大部分依旧采取简单粗暴地取平均方法。从多维度入手，并有侧重加权计算更理性可靠。如果评价数目与类目整体评分高低也纳入考量范畴，也不至于出现所有水果类目全部评分为绿色的情况。精细化评分展示，通过百分比显示用户喜欢程度，或许更容易让消费者做出理性决策。
四、结语
评价系统的公平与好坏不止在电商领域重要，甚至是一些平台生存的依赖，比如豆瓣，美团，更要避免水军刷分等一系列有失公允的违规行为。上至国家企业同样有信用评级，下至个人口头评语，都离不开评论，值得产品深入研究与创新。
欢迎有兴趣的朋友留言一起讨论。
本文由 @产品游侠 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议