技术服务电商平台建设 第1篇
行为都有结果。这是我们给那些在互联网上说我们坏话的人发送邮件的原因，也是我们建立 Pubsub系统的原因。
当新用户注册时，我们希望向他们发送一封电子邮件，欢迎他们加入Steveslist，并提醒他们注意我刚才描述的行为-后果关系。当旧金山有人新增了电视清单，我们想要通知那些针对搜索“旧金山湾区电视”设置了提醒的用户。当信用卡被拒绝订阅时，我们想要给有责任的用户发送电子邮件，礼貌地警示他们。当有新的清单被添加时，我们希望执行一些非常粗略的反欺诈检查。当有人购买了商品时，我们想发送webhook到它的卖家。诸如此类。
从技术上讲，所有这些动作都可以由执行初始化操作的服务器同步（还记得这个词吗？）执行。不过，这通常不是一个好主意，原因有两个。首先，响应动作（比如通过电子邮件通知所有订阅了新增电视通知的用户）可能非常缓慢。同步执行响应动作意味着，如果初始动作是由用户执行的，那么他们将不得不等待所有响应动作完成。如果响应行动小而迅速，比如发送一封电子邮件，这可能不是什么大问题。但如果动作比较大——比如搜索并通知所有可能对新商品感兴趣的用户——那么，这虽然还不算大问题，但会是一个糟糕的用户体验。
为了缓解这个问题，我们构建了一个“Publish-Subscribe”或“Pubsub”系统。当执行触发器动作时，执行该动作的代码“发布一个描述该动作的事件”，例如 NewListingCreated 或 SubscriptionCardDeclined 。这个语境里的“事件”和“发布”定义得相当粗，没有严格的技术定义。事件只是对已发生的事情所做的某种记录，而发布一个事件只是意味着你以某种方式记录下某件事情发生了。至于实现细节，完全取决于正在讨论的pubsub系统。在简单的系统中，事件可能存储在SQL数据库的表中，代码将通过向表写入新记录来发布事件。
在Steveslist ，如果程序员希望在发布特定类型的事件时执行一个响应动作，他们可以编写一个 Consumer 。这是一段“订阅”了某类事件的代码，每当该类型的事件发布时，都会执行这段代码。它使用事件的详细信息（例如，订阅支付失败的用户）来异步执行程序员想要执行的任何动作（例如，向用户发送警示邮件）。
通常，Pubsub系统由一个中央消息代理 管理。系统向代理发布事件，代理负责将事件发送给任何订阅的消费者。这可以使用 推 或 拉 机制来实现。消费者可以通过轮询并反复询问“是否有新事件？”来从代理拉取消息，或者它们可以等待并侦听，代理可以向它们推送新事件通知，例如向它们发送一个HTTP请求。
Pubsub系统有许多好处：
接下来，让我们聊聊大数据。
为理解和优化我们的业务，我们需要能够计算整个Steveslist平台的复杂的统计数据。按国家和城市划分，每天创建多少列表？每个月有多少注册用户在注册后90天内创建了一个列表？
为此，我们需要编写对整个数据进行聚合的数据库查询。我们不想在生产环境的SQL数据库中运行这些查询，因为它们会产生巨大的负载。我们不希望内部分析师发出一个巨大的查询，使我们的生产数据库陷入瘫痪，但我们确实希望为该分析师提供一个非常适合他们需求的工具。让事情变得更加复杂的是，数据库引擎执行小查询（如返回所有属于一个用户的列表）很快，执行巨大的查询（如计算过去的90天里每天每个类别的清单总共消费了多少美元）通常慢得不可接受（或者无法完成）。
尽管如此，在Steveslist成立后大概一年左右的时间里，我们还是冒险在主生产数据库里执行了我们的分析查询。这是一场赌博，但它几乎获得了成功。不管怎样，我们的数据不是太多，我们有更重要的事情需要关注，比如吸引那些创建大数据的客户，总有一天，我们必须找到一个更可扩展的解决方案。
最终，我们用一个过于雄心勃勃的查询搞挂了生产数据库，并因此决定是时候投资数据仓库了。数据仓库是一种非常适合系统范围的大型查询的数据存储。我们的仓库基于一个名为 Hive 的数据库引擎，但是我们也可以选择Presto、Impala、Redshift，或者其他一些竞品。Hive接受SQL编写的查询，但是在比MySQL数据库大得多的大型数据集上执行。
每晚一次，我们将数据从生产SQL数据库复制到Hive。Steveslist分析师和程序员可以使用最满足他们需求的数据库引擎查询相同的数据集。他们可以使用生产SQL数据库执行来自生产系统小而精确的真相查询；使用Elasticsearch进行全文搜索查询；或者使用数据仓库对海量数据进行大型的聚合查询。
外面天黑了，你又饿了。你问，差不多了吧？
“哦，天哪，不，”Kate答道，“我们可以一直继续下去。但这是一个很好的开始。对广泛的主题有广泛的了解是有好处的，但没人需要知道所有的细节。我发现，一旦了解了一些基础知识，你就可以继续学习更多的基础知识，甚至在学习过程中还可以学到一些细节知识。”
你问Kate，是否可以继续详细地阐述下，她对Steveslist未来五年的设想。
“当然，”Kate说。我们将着重讨论下一个真实的大型在线平台的内部情况，包括：
“明早7点见？”
原文链接：
技术服务电商平台建设 第2篇
我们已经看到Steveslist的用户如何使用我们提供的API通过编程的方式与他们的帐户交互。此外，许多用户还希望我们在他们的Steveslist资料发生任何变化时主动告诉他们。例如，假设有人希望完全自动化在Steveslist上销售商品的过程。每当顾客使用我们新推出的、安全可靠的StevePay系统付款时，他们就会向顾客发送一封感谢邮件，并自动指示仓库将电视送到订单上的地址。我们的卖家可以不断地查询Steveslist API，反复询问“有任何新的成交吗？有任何新的成交吗”然而，这将非常低效，会给我们的服务器带来很多不必要的负载。
相反，我们提供了一个名为Webhooks的行业标准系统。Webhook是一个HTTP请求，当用户的帐户发生他们感兴趣的事情时，我们就发送给他们。它包含所有可以用来描述刚刚发生事件的数据，例如，商品ID、价格、买家ID、买家地址等等。Webhook允许用户自动执行响应操作，如前面提到的电子邮件和自动发货。
要使用webhook，用户得告诉我们，他们希望我们将其webhook发送给哪个URL（例如， ）。他们在那个URL上设置了一个Web服务器，用于接收和操作这些webhook通知。
用户将代码部署在自己的Web服务器上，每当收到我们发来的webhook时，这些代码会执行相应的响应动作。我们不仅在购买商品时发送Webhook，还在用户收到信息时发送；当他们的一件商品被管理员删除；或者当买家投诉时。这使得Steveslist卖家不仅可以自动列出商品，还可以自动销售和发货。
Webhook主要有两个地方比较复杂：安全性和可靠性。首先，让我们讨论下安全问题。卖家提供给我们、让我们发送其Webhook的端点，互联网上的任何人都可以访问。任何知道URL的人都能发送假的Webhook，如果我们的卖家不够谨慎，就可能会受攻击者欺骗，例如，发送免费的东西给攻击者。卖家的Webhook URL应该很难找到，因为卖家不会公开它的存在，但隐瞒和安全不是一回事。
为了让我们的卖家验证Webhook真的是由Steveslist发送的，我们会对Webhook的内容进行密码签名。
密码签名是一个深奥而微妙的话题。我们在这里用于确保Webhook安全的用法是一个精简版本。
当卖家启用他们账户的Webhook时，我们会生成一个随机的“共享密钥”。我们告诉卖家，把这个密钥复制到他们的Webhook接收服务器上，并保证它的安全，这样它的值就只有我们和卖家知道。每次发送webhook时，我们都会带着这个共享密钥，通过一个名为HMAC的加密哈希函数将它与Webhook的内容结合起来，得到一个很长的、看似随机但完全确定的Webhook“签名”。
我们会将这个签名包含在Webhook体中， 例如：
当卖家的Webhook接收服务器收到Webhook时，它获取共享密钥和Webhook内容，就像我们所做的那样，计算出期望的签名。然后，将结果与附加到Webhook的签名进行比较；如果相匹配，就接收并处理Webhook。由于签名只能使用我们和卖家都知道的共享密钥生成，所以Webhook接收服务器可以确信Webhook是我们发送的。不过，如果签名不匹配，服务器就会拒绝该Webhook。 请注意，所有的签名验证码都必须由卖方编写和维护。我们可以为他们提供支持和示例，但我们不能强迫他们验证签名的正确性。如果要了解真实的例子，那么可以看看Stripe和 GitHub是如何对Webhook进行签名的。
我们还需要考虑，当我webhook出现错误时会发生什么，以及我们想要向用户保证什么。如果我们试图发送一个Webhook但不能连接到用户的服务器，我们应该做些什么呢？如果我们成功地连接到他们的服务器并发送了Webhook，但是他们的服务器返回一个错误呢？如果我们发送了Webhook，但服务器断开前挂起了二十秒钟，并且没有告诉我们发生了什么事呢？
这里就涉及到权衡取舍，需要清晰的沟通以及管理数量惊人的基础设施。在Steveslist，我们选择保证发送Webhook“至少一次”。也就是说，如果Webhook发送失败，我们会继续尝试（大量但不是无限次），直到它发送成功。如果我们不确定Webhook是成功或失败，我们将继续尝试，直到我们确定一次尝试成功了。偶尔，这可能会导致我们将相同的Webhook发送两次，但这就是卖方的责任，让他们的代码做个优雅的处理，而不是客户定了一台电视，他们发五台。
“到目前为止你觉得怎么样？”Kate问。“你大概就是这么想的吧？”你摆出一副不置可否的表情，然后咬了一大口旁边的三明治，以避免进一步的讨论。Kate继续讲了下去。
让我们来谈谈后端系统，它将支持一些最重要的特性。
技术服务电商平台建设 第3篇
莞云麦超：购买软件的坑之底层架构支撑不了运营，项目无以为继（非常普遍）： 一分钱一分货，大部分市场开发好的现有模板系统，底层架构基本都很差，完全没有安全性、稳定性可言；一旦用户增多或者数据量上来，就很容易卡死，甚至要重构整个系统架构辛苦运营的用户要推倒重来。此时进行二次开发又带来了新老版本以及数据的兼容问题，底层架构对后期二次开发的接口没有预留，导致二次开发成本将倍增数倍，很多创业项目都是在卡在技术这里无法进行下去，进退不得，*后项目倒闭。解决建议：购买系统前考察系统的底层架构扩展性稳定性，预留的开发接口的丰富性，选择有大客户案例、并且系统应用可以快速个性定制的技术公司 伴随着早期微信群私域的红利过去后和商户私域实践的纵深，公私域联动正在成为 2022年私域布局的新趋势——公域辅助必不可少，是私域重要 **的来源。公域能够为商户提供“活水”，是私域**的重要来源，决定了私域留存与运营的效率。多渠道布局与联动能够为用户创设更多消费场景，**消费粘性，有利于私域留存与运营，公私域联动具备长期价值，商户可以基于全域视角来洞察消费者的痛点、分析数据，制定相应的营销策略。 目前，主要的私域平台均已陆续发力公私域联动。
技术服务电商平台建设 第4篇
我们允许用户和第三方以编程方式与平台交互，就像人们可以使用Twitter API编写代码来读取、喜欢和创建推特，我们也允许他们使用Steveslist API进行搜索、购买和罗列物品。
程序员可以通过编写代码使用我们的API，向API端点发出HTTP请求。例如，为了检索所有清单的列表，程序员向 发送一个HTTP GET 请求。我们以 JSON格式的数据响应他们的请求。JSON是JavaScript Object Notation的缩写，但是JSON不是JavaScript特有的，使用任何编程语言都可以很容易地解析。对于检索所有用户清单的请求，JSON响应可能是下面这样：
对程序来说，这种结构化的响应格式非常容易解析，这意味着发出请求的代码可以轻松地解析和使用来自API的数据。用户使用API Key向我们的API标识自己或进行身份验证。大概来说，这相当于API的密码。它是一个随机的长字符串，我们生成并显示在用户的“设置”页面上。用户将他们的API Key作为HTTP头包含在他们（或他们的代码）向API发出的每个HTTP请求中。当我们收到一个API请求时，我们检查附加的API Key是否对应于一个Steveslist用户。如果是，我们就代表该用户执行该请求。
如果程序员愿意，他们也可以用他们所使用的开发语言中提供的标准HTTP库手工构建发送给API的HTTP请求。例如，在Python中，他们可能会这样写：
不过，为了简化程序员的工作，我们会提供客户端库 。
技术服务电商平台建设 第5篇
管理Steveslist平台需要定制内部工具。我们需要执行各种各样的管理任务，比如删除不合规的列表（即使对我们来说也是如此）、发起退款、查看用户的个人信息以帮助处理支持请求等等。在这些工具中，有许多将被Steveslist其他团队的人使用，比如财务、合规、法律、销售支持等团队。由于它们需要执行的任务与Steveslist的工作方式紧密相关，因此我们不能使用第三方工具来完成，而必须构建自己的工具。
早期，我们将这个功能添加到主要的Stevelist产品中，只向设置了 is_steveslist_employee = True 数据库标识的用户公开。对于小公司来说，这是一个不错的方法，但很脆弱，也很容易出问题。一想到会把超级用户能力暴露在运行主要产品的同一台服务器上，我们就感到害怕。它会使应用程序安全缺陷的潜在后果变得更严重，并导致了新的错误类型，例如忘记为一个被解雇的员工禁用 is_steveslist_employee 标识。
一旦Steveslist达到一定的成熟水平，我们就为自己构建了一个完全独立的管理平台，使用单独的、经过增强的身份验证和授权。该服务运行在完全独立的服务器上，需要 VPN 和 TLS客户端证书 才能访问（这个问题我们将在以后讨论）。这样就将我们的内部产品和外部产品分开了，大大减少了因一个愚蠢的错误而暴露我们管理工具的机会。我们经常构建新的内部工具——一个用于用户管理，一个用于服务器管理，一个用于欺诈检测等等。这些服务都与我们面向用户的产品使用相同的数据库，因此，它们都可以访问相同的数据。它们只是运行在不同的服务器上，外部世界完全无法访问这些服务器。