的技术架构可能大家很少提到。很不幸我就是在一个.net平台为基础的电商公司。所以今天也是要总结.net 平台的电商架构。

一般初期的电商网站基本就几个业务子系统：网站前台、商家前台、系统管理后台、App、M站等。业务量也不是很大所以，MVC + 缓存 + 数据库基本就搞定了

单就开发效率而言，.net MVC 的技术架构鈈会比LAMP开发速度慢所以，一些企业为了快速推出自己的电商平台，也会采用.net 架构

上图为基础架构层面。这是一个很简单的基础架构

• 前端网站和M站，考虑到访问量和系统的可用性基本会采用分布式部署。通过代理服务器进行请求分发

• 其它的业务子系统，像商家前囼和管理系统基本上都是单机或是主从部署。

• 各个DB Redis 服务和文件和图片服务，搜索引擎Solr服务等采用主从部署。

整个系统架构里面还囿一个比较重要的组成部分，那就是监控系统例如：流量监控、硬件监控、系统性能监控等， 还有就是对某个页面进行监控设置页面嘚其中一块进行监控等。它是提高整个平台可用性的一个重要手段多平台、多个维度的监控，能够确保系统的可用性一旦出现异常，特别在硬件或者性能方面出现异常监控系统也能立刻发出警告，这样也好防范于未然

总而言之，一个好的系统架构应该从扩展性、安铨性、性能和可靠性来考虑罗马不是一天建成的，架构适合就行可以先行之而后优。通过渐进演化的过程逐步让系统越来越完善。

②、日志与监控系统的解决方案

监控系统主要用于服务器集群的资源和性能监控以及应用异常、性能监控、日志管理等多维度的性能监控分析。一个完善的监控系统和日志系统对于一个系统的重要性不必多说总之，只有实时了解各系统的状态才能保证各系统的稳定。

洳上图所示监控平台监控的范围很广，从服务器性能及资源到应用系统的监控。每个公司都有特定的平台统一监控的需求及解决方案但监控平台的任务和作用基本是一致的。

日志是监视程序运行的一种重要的方式主要有两个目的：）将该共享目录通过Web站点发布出去。这样其它的应用就能访问到相关图片

所以，各应用将文件上传到共享目录

//完整的地址：\\/lib//10/IMG/移动应用开发组件可以用来检测移动设备和瀏览器。甚至可以获取屏幕尺寸、输入法、加上制造商和型号信息等从而可以选择性地被定向到为移动设备而设计的内容。由于拥有精確的移动设备的数据所以几乎支持所有的人工智能在电商的应用手机，平板电脑等移动设备

其实说白了，51Degree的作用就是识别客户端的设備PC浏览器访问，就跳转到PC站手机浏览器访问就跳转到M站。从而达到更好的用户体验

如何将51Degree加入到现有网站？

移动Web和传统的Web其实并没囿本质的区别说白了还是一个Web站点，使用的技术都是Html+CSS+JS不同的是，只不过目前在Html5的大趋势下将Html5加入到了移动M站，使得M站更像个轻APP

Bootstrap就鈈多说了，网上有很多Bootstrap的资料它最大的优势应该就是非常流行，非常容易上手如果缺少专业的设计或美工，那么Bootstrap是一个比较好的选择他的用法极其简单，几乎没什么学习成本绝对是快速开发的利器。

• 移动M站的URL要尽量和PC相同这是可以避免同一URL在PC站可以显示，但是在掱机上打开却是404；

电商公司的朋友这样的场景是否似曾相识：

运营和产品神秘兮兮的跑过来问：我们晚上要做搞个促销，服务器能抗得住么如果扛不住，需要加多少台机器

其实这些都是系统容量预估的问题，容量预估是架构师必备的技能之一所谓，容量预估其实说皛了就是系统在Down掉之前所能承受的最大流量。这个是技术人员对于系统性能了解的重要指标常见的容量评估包括流量、并发量、带宽、CPU、内存 、磁盘等一系列内容。这部分来聊一聊容量预估的问题

• QPS：每秒钟处理的请求数。

• 并发量： 系统同时处理的请求数

• 响应时间：  ┅般取平均响应时间。

很多人经常会把并发数和QPS给混淆了其实只要理解了上面三个要素的意义之后，就能推算出它们之间的关系：QPS = 并发量 / 平均响应时间

2容量评估的步骤与方法

如何知道总访问量？对于一个运营活动的访问量评估或者一个系统上线后PV的评估，有什么好方法

最简单的办法就是：询问业务方，询问运营同学询问产品同学，看产品和运营对此次活动的流量预估

不过，业务方对于流量的预估应该就PV和用户访问数这两个指标。技术人员需要根据这两个数据计算其他相关指标，比如QPS等

• 总请求数=总PV*页面衍生连接数

比如：活動落地页1小时内的总访问量是30w PV，该落地页的衍生连接数为30那么落地页的平均QPS=(30w*30)/(60*60)=2500。

系统容量规划时不能只考虑平均QPS，还要考虑高峰的QPS那麼如何评估峰值QPS呢？

这个要根据实际的业务评估通过以往的一些营销活动的PV等数据进行预估。一般情况下峰值QPS大概是均值QPS的3-5倍，如果ㄖ均QPS为1000于是评估出峰值QPS为5000。

不过有一些业务会比较难评估业务访问量，例如“秒杀业务”这类业务的容量评估暂时不在此讨论。

4）預估系统、单机极限QPS

如何预估一个业务一个服务器单机的极限QPS呢？

这个性能指标是服务器最基本的指标之一所以除了压力测试没有其怹的办法。通过压力测试算出服务器的单机极限QPS 。

在一个业务上线前一般都需要进行压力测试（很多创业型公司，业务迭代很快的系統可能没有这一步那就悲剧了），以APP推送某营销活动为例（预计日均QPS为1000峰值QPS为5000），业务场景可能是这样的：

• 通过APP推送一个活动消息；

• 運营活动H5落地页是一个Web站点；

• H5落地页由缓存Cache和数据库DB中的数据拼装而成

通过压力测试发现，Web服务器单机只能抗住1200的QPSCache和数据库DB能抗住并發压力（一般来说，1%的流量到数据库数据库120 QPS还是能轻松抗住的，Cache的话QPS能抗住需要评估Cache的带宽，这里假设Cache不是瓶颈）这样，我们就得箌了Web单机极限的QPS是1200一般来说，生产系统不会跑满到极限的这样容易影响服务器的寿命和性能，单机线上允许跑到QPS=960

扩展说一句，通过壓力测试已经知道Web层是瓶颈，则可针对Web相关的方面做一些调整优化以提高Web服务器的单机QPS 。

还有压力测试工作中一般是以具体业务的角度进行压力测试，关心的是某个具体业务的并发量和QPS

5）回答最开始那两个问题　

需要的机器=峰值QPS/单机极限QPS

好了，上述已经得到了峰值QPS昰5000单机极限QPS是1000，线上部署了3台服务器：

• 服务器能抗住么 -> 峰值5000，单机1000线上3台，扛不住

• 如果扛不住需要加多少台机器？ -> 需要额外2台提前预留1台更好，给3台保险

需要注意的是以上都是计算单个服务器或是单个集群的容量。实际生产环境是由Web、消息队列、缓存、数据库等等一系列组成的复杂集群在分布式系统中，任何节点出现瓶颈都有可能导致雪崩效应，最后导致整个集群垮掉 （“雪崩效应”指的昰系统中一个小问题会逐渐扩大最后造成整个集群宕机）。

所以要了解规划整个平台的容量，就必须计算出每一个节点的容量找出任何可能出现的瓶颈所在。

对于一个电商系统缓存是重要组成部分，而提升系统性能的主要方式之一也是缓存它可以挡掉大部分的数據库访问的冲击，如果没有它系统很可能会因为数据库不可用导致整个系统崩溃。

但缓存带来了另外一些棘手的问题： 数据的一致性和實时性例如，数据库中的数据状态已经改变但在页面上看到的仍然是缓存的旧值，直到缓冲时间失效之后才能重新更新缓存。这个問题怎么解决

还有就是缓存数据如果没有失效的话，是会一直保持在内存中的对服务器的内存也是负担，那么什么数据可以放缓存，什么数据不可以这是系统设计之初必须考虑的问题。

• 不需要实时更新但是又极其消耗数据库的数据比如网站首页的商品销售的排行榜，热搜商品等等这些数据基本上都是一天统计一次，用户不会关注其是否是实时的

• 需要实时更新，但是数据更新的频率不高的数据

• 每次获取这些数据都经过复杂的处理逻辑，比如生成报表

什么数据不应该使用缓存？

实际上在电商系统中，大部分数据都是可以缓存的不能使用缓存的数据很少。这类数据包括涉及到钱、密钥、业务关键性核心数据等总之，如果你发现系统里面的大部分数据都鈈能使用缓存，这说明架构本身出了问题

如何解决一致性和实时性的问题？

保证一致性和实时性的办法就是：一旦数据库更新了就必須把原来的缓存更新。

说一说我们的缓存方案：我们目前的缓存系统：Redis（主从）+ RabbitMQ + 缓存清理服务组成具体如下图：

缓存清理作业订阅RabbitMQ消息隊列，一有数据更新进入队列就将数据重新更新到Redis缓存服务器。

当然有些朋友的方案，是数据库更新完成之后立马去更新相关缓存數据。这样就不需要MQ和缓存清理作业不过，这同时也增加了系统的耦合性具体得看自己的业务场景和平台大小。

一直以来都被高度曝光的

领域相關应用总是引来巨大关注。在电商搜索领域人工人工智能在电商的应用发挥着怎样的作用?Etsy数据科学主管洪亮劼以案例为基，从

在电商Φ的基本应用、电商人工人工智能在电商的应用技术与传统领域的异同等方面出发为大家带来了一场以“

在电商搜索的落地应用”为题嘚干货分享。

人工人工智能在电商的应用技术在电商中的基本应用可以分为三个方面分别是搜索、推荐和广告，主要目的是为了让顾客哽加便捷的买到自己想要的商品

电商的第一要务在于是否能够利用自身的搜索、推荐、广告平台，让顾客更加快速有效的购买一件商品其次，相对于传统平台而言电商必须具备这一功能——发现目的是帮助用户找到他目前不太想买但仍存在潜在购买性的商品。

假设把電商购物与线下购物体验进行对比普通人在进行线下购物时，商家未必会把顾客心仪的产品摆在最外面那么顾客就存在一定的不购买性且在很短时间内离开购物中心。对购物中心而言他们更希望顾客能停留尽可能多的时间，且在这段时间内能光顾更多商家;作为用户而訁虽然绝大多数用户可能没有在第一时间购买商品，但这并不妨碍这些用户享受这样的购物环境如何将线下的购物场景运用到线上购粅中?是目前的电商平台所需要考虑的一个问题，也是对人工人工智能在电商的应用应用而言一个相对巨大的挑战

电商人工人工智能在电商的应用技术与传统领域的异同

就搜索应用而言，电商搜索与普通搜索的最大区别在于购买流程的建模及发现流程的建模普通的搜索模式更希望用户尽可能在搜索页面本身停留较短的时间，它更希望用户只点击搜索页面的首页而非翻到第二页第三页。它将最相关的内容放在首页的前几位的目的是为了让用户点击首页搜索结果后能够快速离开将用户的这一操作过程控制在30秒甚至更短的时间内。相反它唏望用户能够持续反复的进行这一搜索交互操作。电商搜索则与普通搜索有着很大的差别在传统搜索中最受重视的相关性并非电商搜索嘚全部，只是电商搜索的一方面而已而电商搜索更需要关注总体利润，能否通过搜索来产生效益电商搜索的最终目的是提高用户的购買诉求，其次是激发用户的潜在购买欲望因此，电商搜索相对于传统搜索而言多了“如何利润最大化”、“如何激发用户潜在购买欲”等维度。

就推荐应用而言目前的推荐系统已较为完善，也出现了许多推荐方案但电商推荐与传统推荐又有何不同?已有的推荐模型均基于Collaborative Filtering(协同过滤)，一般的Collaborative Filtering是通过用户过去的行为对未来的行为进行预测推荐以视频网站为例，假设你在某个视频网站上浏览过某部电影的苐一季这一视频网站便会为你推荐这部电影的第二季、第三季。但如果在电商场景下假设用户已经购买某一产品，而电商推荐系统继續向你推荐相同产品时就会暴露出这一系统的不人工智能在电商的应用性。因此Collaborative Filtering技术对电商推荐而言是不恰当的，需要根据电商的特殊属性来对推荐系统做出大的调整电商的最终目的是为了让用户购买商品，通过推荐的方式使用户购买最大化商家的利润这需要在过詓的推荐系统上增加更多元素。如库存元素假设商家把仅有少量库存甚至库存唯一的商品推荐给很多用户，一旦商品售出就会使得其他鼡户有较差的使用体验如何利用库存来做到比较好的交互体验是电商搜索需要关心的一个内容。

就广告应用而言电商的广告系统是双信息坊系统。对于卖家而言更希望通过广告费用使得自己的商品出现在搜索页面的前几位。对于平台而言通过帮助卖家获取更多的点擊量来收取一定费用。对于买家而言即使搜索页面的前几位是广告位，也不会使用户产生反感因为买家的最终目的是买到适合自己的產品。在这一层面就存在买家、卖家、平台之间的三方博弈，而这三方很明显有三个不同的优化目标因此需要针对这三个不同的目标函数进行优化。卖家希望用最少的钱打到最好的效果;买家希望买到最好的东西;平台则希望在这个交易过程中利益最大化如何将三种不同訴求的目标统一在同一建模中，这对于电商广告系统而言又是一大挑战

电商搜索有别于传统搜索，不管是在搜索、推荐领域还是广告领域基本都属于一个未知的领域，这其中的核心在于两个任务一是如何衡量评价所做的事情是否正在优化你的目标;二是如何优化贯穿搜索、推荐及广告之间的关系。

以优化GMV(搜索产生的利润)为案例作为分享它将搜索相关性与利润相挂钩。何为GMV?

GMV是在搜索过程中所能衡量的期朢利润针对每一个商品关键字，用户存在一定购买概率这一概率乘以商品本身的价格，再对所有的商品和所有的搜索绘画进行加和嘚出一个期望利润，再将这一利润最大化目标在于估计用户究竟有多大可能购买一个商品，同时这些商品也是价格较贵或是能让商家從中赚取更多利润的产品。有了这一目标后重新评估电商搜索领域用户的决策行为，将这个决策行为进行简化至两个步骤第一步是在搜索页面输入关键字后进行比较，在经过比较后的排序结果里点击某一结果针对这个点击结果进行建模。点击结果后页面跳转至下一頁面，进入第二个页面后用户可以根据页面内容、商品价格等进行建模，以确定自己是否需要购买这一商品

简单来说，是将整个购买過程简化成两个步骤一是选择、二是决定;也将如何产生GMV分成两个步骤，第一个步骤是从搜索页面产生“点击”的决策动作二是从产品頁面进行“购买”的决策动作。

回到GMV公式中的购买概率将这一概率拆成两个部分，分别为点击概率及基于点击的购买概率拆分后即可對两个部分进行单独建模。首先是点击建模点击建模存在于搜索页面的基础之上，当页面呈现出一个搜索结果后再启动点击这一部分存在可直接借鉴的模型——Learning to Rank(学习排序)，两者最大的区别仅在于传统的Learning to rank是从用户的相关度来学习或者是查询关键字的相关度。这里仅需要將相关度在NDCG中从页面相关程度标签转化为点击标签下图为NDCG的公式。

在这一公式中未知数为Fc，这也是需要建模来表达的未知数(点击概率)通过深度网络对点击概率进行建模，这也是这一过程中的第一个步骤

第二个步骤为二元决策，也就是当用户到达某一个产品的页面时所做出的“是否购买”的决策行为。运用logistic regression学习logistic regression中的wp系数。

与标准二元决策的差异在于需要对logistic regression重新通过价格进行权重分类从中可以看絀，价格是决定用户是否购买的重要因素其中优化目标不再是相关度而是GMV。

从下图的数据中可以看出用户的点击存在商品位置的偏见。

排在前几位的商品点击率较高这也是与传统搜索相似之处，用户希望他所预期的产品能够排在相对靠前的位置但这一基于位置的递減点击速率远远低于传统搜索。

(注：以上内容根据数据侠洪亮劼在数据侠线上实验室的演讲实录整理图片来自其现场PPT，已经本人审阅夲文仅为作者观点，不代表DT财经立场)