通过本文，你将了解到如何利用微服务分布式架构设计一个高可用、高可扩展、低延迟且对网络故障有弹性的系统，以处理数以百万计的请求。
本文将教给你如何从单体架构一步步演进到事件驱动的微服务架构。
我们将从基本的软件架构设计入手，设计一个可以处理少量请求的单体架构的电子商务应用。
之后，我们将介绍该架构如何一步步演进：
本文既有理论知识，又有实用信息：
因此，我们会对架构进行迭代设计，从单体架构逐步演进为事件驱动的微服务架构。
我们将根据以下问题来演进架构：
因此，我们是从以下几个方面来改进架构：
可扩展性 = 电子商务应用程序应能为数百万用户提供服务
可用性 = 电子商务应用应该 7*24 小时可用
可维护性 = 电子商务应用应该可以发展数年之久
效率 = 电子商务应用的响应延迟在可接受的范围内，如小于 2 秒，即低延迟
现在让我们看下可接受的延迟。如果我们的应用程序用户越来越多，我们如何让应用程序的延迟在可接受的范围内？请看下表：
之后，随着业务不断增长，它将需要更多的资源来适应更大的请求数，你将看到我们如何根据这些数值来演进我们的架构。
几十年的软件开发演变出了许多方法和模式，它们各有各的优势，也都面临着各自的挑战。
因此，我们将从理解现有的方法入手来设计电子商务应用的架构，并逐步演进转移到云上。
为了理解云原生微服务，我们需要理解什么是单体应用程序，以及我们如何从单体架构迁移到微服务架构。
如果一个项目的所有功能都在一个代码库中，那么该应用就是单体应用。在单体模式中，用户界面、业务代码和数据访问的所有东西都在同一个代码库里。
所有应用关注点都包含在一个大的部署中。即使是单体应用也可以设计出不同的层次，如表现层、业务层和数据层，然后将该代码库部署为单个 jar/war 文件。
单体方法也有不少优点，我们将在即将推出的视频中讨论它们。在这里，我将介绍一些主要的优缺点。
由于只有一个代码库，所以很容易拉取并参与其中。而且，因为在同一个项目中，所以不同模块间的业务交互很容易调试。
遗憾的是，单体架构有许多许多缺点，如：
如你所见，我们了解单体架构。
虽然单体架构有很多缺点，但如果你正在构建一个小型应用程序，那么单体架构仍然是你可以在项目中采用的最佳架构之一。因为，在许多方面，单体应用程序都比较简单。
它们很容易：
与需要有经验的开发人员来识别和开发服务的微服务架构相比，它的开发相对简单。它更容易部署，因为只需要部署一个 jar/war 文件。
在这一节中，我们将使用单体架构一步一步地设计我们的电子商务应用程序。我们将根据需求逐步对架构设计进行迭代。
我们应该总是从编写 FR（功能需求）和 NFR（非功能需求）开始。
此外，最好在架构图中加上规则，以免忘记。
我们在设计架构时会考虑这些规则。
我们添加了一个大的 E-Commerce 框，它是电子商务应用程序的组成部分，其中包括商店用户界面、分类服务、SC 服务、折扣服务、订单服务。如你所见，这个传统 Web 应用程序的所有模块是容器中的一个工件。
这个单体应用有一个庞大的代码库，其中包括所有模块。如果要在这个应用程序中增加新模块，就必须对现有的代码进行修改，然后将代码修改后的工件部署到 Tomcat 服务器上。简单起见，我们遵循 KISS 原则。
我们将根据需求重构我们的设计，并一步步进行迭代。
从图中可以看出，我们增加了 2 台应用服务器，对单体架构做了横向扩展，并在单体应用的客户端和电子商务应用之间加了一个负载均衡器。
在单体架构中，为了实现扩展，我们需要增加 E-Commerce 应用服务器，并在应用程序之前放一个负载均衡器。
本质上，负载平衡器将接受请求并使用一致性哈希算法将请求发送到电子商务应用服务器，保证服务器的负载都一样。
现在我们看下技术选项——适配技术栈。
微服务是小型的业务服务，它们可以自主 / 独立部署，协同工作。
以下内容来自 Martin Fowlers 介绍微服务的文章：
微服务架构风格是一种将单个应用开发成一套小型服务的方法，每个服务都在自己的进程中运行，并通过轻量级的机制进行通信，通常是 HTTP 或 gRPC API。
因此，我们可以说，微服务架构是一种云原生的架构方法，利用这种方法设计出的应用程序由许多松耦合的、独立部署的小型组件组成。
微服务
——有自己的技术栈，包括数据库和数据管理模型；
——通过 REST API、事件流和消息代理等相互通信；
——按业务能力来组织，划分服务的界限通常被称为有界上下文。
在接下来的章节中，我们还将看到，如何利用有界上下文解耦微服务。
微服务的特点是小、独立和松耦合。一个小型开发团队就可以编写和维护一个服务。每个服务都有一个独立的代码库，可以由一个小型开发团队来管理。
服务可以独立部署。团队可以更新一个现有的服务，而不需要重新构建和部署整个应用程序。
服务负责持久化它们自己的数据或外部状态。这点与传统模式不同，在传统模式中，有一个单独的数据层处理数据持久性。
敏捷性
微服务最重要的一个特点是小，可以独立部署。
目标明确的小型团队
微服务应该足够小，以至于一个单功能团队就可以构建、测试和部署它。
可扩展性
微服务可以独立扩展，你可以单独扩展某个子服务，而无需扩展整个应用程序。
复杂性
微服务应用程序有很多服务组成，这些服务需要协同工作来创造价值。由于服务很多，与单体应用相比，这意味着更多的移动部件。
网络问题和延迟
由于微服务很小，而且服务之间需要通信，所以我们要管理网络问题。
数据一致性
微服务有自己的数据持久化。因此，数据一致性会成为一项挑战。
在这一节中，我们将一步步地设计微服务架构，并根据需求，逐步迭代架构设计。
如此一来，现在这些数据库就可以是混合持久化。也就是说，根据每个微服务的存储需求不同，Product 微服务可以使用 NoSQL 文档数据库，SC 微服务可以使用 NoSQL 键值对数据库，Order 微服务可以使用关系型数据库。
让我们看下这个微服务架构图，并思考一下这个架构缺少了什么？这个架构的痛点是什么？我们怎么改进这个架构，才能提供更高的可扩展性、可用性，并且支撑更多的并发请求？
我们看到，UI 和微服务是直接通信的，这看上去很难管理。我们现在应该重点关注下微服务通信。
当迁移到基于微服务的应用程序时，最大的挑战之一是通信机制的变化。因为微服务是分布式的，微服务之间的通信是通过网络层面的服务间通信完成的。每个微服务都有自己的实例和进程。
因此，服务必须使用服务间通信协议，如 HTTP、gRPC 或消息代理协议 AMQP 进行交互。
由于微服务拥有复杂的结构，服务都是独立开发和部署，所以我们在考虑通信类型时应该谨慎，并在设计阶段做妥善处理。
如果你想基于微服务设计和构建具有多个客户端应用程序的复杂的大型应用程序，则建议使用 API 网关模式。
该模式提供了一个反向代理，将请求重定向或路由到内部微服务端点。API 网关为客户端应用程序提供一个单一的端点，它会在内部将请求映射到内部微服务。我们应该在客户端和内部微服务之间使用 API 网关。
API 网关可以处理像授权这样的横切关注点。因此，授权可以在集中式的 API 网关中处理，并发送给内部微服务，而不是在每个微服务中编写相关代码。同时，API 网关控制到内部微服务的路由，并能够将几个微服务的请求汇总到一个响应中。
总之，API 网关位于客户端应用程序和内部微服务之间。作为一个反向代理，它将请求从客户端路由到后端服务。它还提供横切关注点，如身份认证、SSL 终止和缓存。
我们将对电子商务应用程序的架构进行迭代，增加 API 网关模式。
它将处理客户端请求，并提供内部微服务路由。它还可以聚合多个内部微服务来响应一个客户端请求，并提供横切关注点，如身份认证和授权、速率限制和节流等等。
我们将继续演进我们的架构，但请看一下当前的设计，考虑下我们可以如何改进？
这里，有多个客户应用程序连接到单个 API 网关。我们应该小心这种情况，因为如果我们在这里只放置一个 API 网关，这意味着这里存在单点故障的风险。如果客户端应用程序增加，或 API 网关中业务逻辑的复杂性增加，这将是一种反模式。
因此，我们应该用 BFF-backends-for-frontends 模式解决这个问题。
基本上，Backends for Frontends 模式是针对特定的前端应用程序设置单独的 API 网关。我们有多个供前端应用消费的后端服务，我们在它们之间设置了 API 网关，用于处理路由和聚合操作。
不过，这产生了单一故障点。为了解决这个问题，BFF 提供了多个 API 网关，并根据客户端应用程序的边界进行分组，然后划分到不同的 API 网关。
所以我们应该根据用户界面的不同创建多个 API 网关。这些 API 网关可以与前端环境实现最佳匹配，而不用担心影响其他前端应用程序。
Backend for Frontends 模式为实现多网关指明了方向。
我们将根据 Backends for Frontends（BFF）模式迭代我们的电子商务应用架构，增加 API 网关。
我们已经在微服务架构中创建了 API 网关，而且已经说过，来自客户端的所有同步请求都通过 API 网关进入内部微服务。
但是，如果客户端请求需要访问多个内部微服务怎么办？我们如何处理内部微服务之间的通信？
然而，在某些情况下，由于客户的要求或所请求的操作需要访问几个内部服务，我们无法减少内部通信。
例如，对照上图考虑这样一种情况：用户想要结账并创建一个订单。
我们该如何满足这个请求？
这些调用把微服务耦合在了一起，在我们的例子里，微服务 Product 和 Pricing 就会相互依赖并耦合。如果其中一个微服务发生故障，它就不能向客户端返回数据，所以它没有任何容错性。如果微服务之间的依赖性和耦合性增加，就会产生很多问题，并缩小微服务架构的优势。
如果客户要对购物车进行结账，这将触发一系列的操作。因此，如果我们试图用请求 / 响应这种同步消息模式来执行这个下单用例，那就会像上面这个图一样。
可以看到，一个客户端的 http 请求会触发 6 个同步 http 请求。所以显然会增加延迟并对系统的性能、可扩展性和可用性产生负面影响。
如果我们有这样的用例，如果第 5 步或第 6 步失败了，或者中间的某些服务中断了怎么办？即使没有中断，某些服务也可能非常繁忙，无法及时响应，造成不可接受的高延迟。
那么，这类需求的解决方案是什么？
我们可以通过两种方法来解决这种问题：
为了尽量减少服务之间的通信，我们可以使用服务聚合模式。基本上，服务聚合设计模式是接收来自客户端或 API 网关的请求，然后分配给内部多个后端微服务，再将结果合并，并在一个响应结构中发给请求发起人。
在这一节中，我们将通过添加服务聚合模式 / 服务注册模式，来迭代我们的电子商务应用架构。
如果通信只是在少数几个微服务之间进行，那么同步通信就很好。但当涉及到多个微服务相互调用，并且要等待一些长时间的操作完成时，我们应该使用异步通信。
如果你有多个微服务需要彼此交互，而且，你希望这种交互没有任何依赖性或是松耦合的，那么我们就应该在微服务架构中使用基于异步消息的通信。
因为基于异步消息的通信有赖于事件，所以我们称这种通信为事件驱动的通信。
发布 - 订阅是一种消息传递模式，它的消息发送者被称为发布者，而特定的接收者被称为订阅者。
在这一节中，我们将添加发布 / 订阅消息代理，提供微服务异步通信设计，完成电子商务应用的架构迭代。
如果要适配技术栈，那么我们首先会考虑选用什么发布 / 订阅消息代理。下面这两个都是不错的选项：
在单体架构中，查询不同的实体非常方便，因为是由单个数据库来管理数据，这会很简单。多表关联查询也很简单。对数据的任何修改都会一起更新，或是一起回滚。关系型数据库具有严格的一致性，有 ACID 事务保证，所以管理和查询数据都很容易。
但在微服务架构中，当我们使用“混合持久化”时，这意味着每个微服务都有不同的数据库，包括关系型数据库和 NoSQL 数据库，我们应该制定一个策略，在进行用户交互时管理好这些数据。
因此，这意味着我们在处理微服务之间的数据交互时有几种模式和做法，我们将在本节中学习这些模式和原则。
微服务是独立的，只执行特定的功能要求。在我们的电子商务应用中，我们有产品、购物车、折扣、订单等微服务，它们需要彼此交互来满足客户的要求。这意味着它们需要频繁地交互。而这些交互大多是查询每个服务的数据以进行聚合或执行逻辑。
CQRS 是跨微服务查询的重要模式之一。我们可以使用 CQRS 设计模式，以避免复杂的查询，摆脱低效的连接。CQRS 是命令和查询责任隔离的意思。本质上，这种模式实现了数据库读取和更新操作的分离。
为了隔离命令和查询，最好的做法是用 2 个数据库物理地分离读和写数据库。此时，如果我们的应用程序是读密集型的，也就是读比写多，我们就可以通过定义自定义数据模式来优化查询。
通过这种隔离，对于读数据库和写数据库，我们甚至可以使用不同的数据库类型，如使用 NoSQL 文档数据库进行读取，使用关系数据库进行 CRUD 操作。
我们已经学习了 CQRS 模式，该模式主要是与事件源模式一起使用。当搭配使用 CQRS 与事件源模式时，主要的理念是将事件存储到写数据库中，这将是作为真相来源的事件数据库。
之后，CQRS 设计模式的读数据库通过非规范化表提供数据的物化视图。当然，这个物化视图的读数据库消费了来自写数据库的事件，并将它们转换为非规范化的视图。
它不更新数据记录的状态，而是将每个修改追加到一个事件的顺序表中。因此，事件存储成为数据的真实来源。之后，这些事件存储通过物化视图转换为读数据库。这种转换操作可以通过发布 / 订阅模式来处理，实现方式是用消息代理系统发布事件。
我们将在电子商务应用的架构中应用 CQRS、事件源、最终一致性、物化视图。
现在我们可以考虑这些数据库的技术栈了，我打算用 SQL Server 作为关系型写数据库，用 Cassandra 作为 NoSQL 读数据库。当然，我们将使用 Kafka 的发布 / 订阅主题交换来同步这两个数据库。可以看到，我们已经完成了微服务数据库模式的设计。现在，让我们深入了解下微服务中的事件驱动架构。
本质上，事件驱动的微服务架构是指通过事件消息传递实现微服务之间的通信。在微服务异步通信那一节，我们已经从发布 / 订阅模式和 Kafka 消息代理系统中了解了这种方式。
我们说，通过事件驱动架构，我们可以实现异步行为和松耦合的结构。例如，服务不是在需要数据时发送请求，而是通过事件来消费它们。这可以提高性能。
因此，我们可以使这种事件驱动的方法更加通用，并通过实时事件处理特性来演进架构。
在这个新的事件驱动的微服务架构中，所有通信都是通过事件中心（Event-Hub）进行的。可以认为，事件中心是一个可以完成实时处理的大型事件存储数据库。
我们将利用事件驱动的微服务架构来设计我们的电子商务应用。
如你所见，现在我们用事件驱动的微服务架构实现了反应式设计。
现在，我们可以问同样的问题：我们的设计可以满足多大的并发请求？
这个架构是完全松耦合的，并且做了高可扩展性和高可用性设计。
如你所见，我们完成了电子商务微服务架构的设计，这个过程涉及了所有的设计原则和模式。通过学习，你已经了解如何在设计中使用这些设计模式了，现在你可以设计自己的架构了。
本文由哈喽比特于3年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/o0g-S8lv52qd0lHUfQ6Bkg
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而，京东官方通过微博发言人发布的消息澄清了这些传言，称这些言论纯属虚假信息和蓄意捏造。
日前，据博主“@超能数码君老周”爆料，国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道，荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦（ASML）CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候，抖音悄然上线了一款名为“青桃”的 App，Slogan 为“看见你的热爱”，根据应用介绍可知，“青桃”是一个属于年轻人的兴趣知识视频平台，由抖音官方出品的中长视频关联版本，整体风格有些类似B站。
日前，威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”，同时，他发文表示：中国汽车普及率低于非洲国家尼日利亚，每百户家庭仅17户有车。意大利世界排名第一，每十户中九户有车。
近日，一项新的研究发现，维生素 C 和 E 等抗氧化剂会激活一种机制，刺激癌症肿瘤中新血管的生长，帮助它们生长和扩散。
据媒体援引消息人士报道，苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后，3D系统一度大涨超10%，不过截至周三收盘，该股涨幅回落至2%以内。
9月2日，坐拥千万粉丝的网红主播“秀才”账号被封禁，在社交媒体平台上引发热议。平台相关负责人表示，“秀才”账号违反平台相关规定，已封禁。据知情人士透露，秀才近期被举报存在违法行为，这可能是他被封禁的部分原因。据悉，“秀才”年龄39岁，是安徽省亳州市蒙城县人，抖音网红，粉丝数量超1200万。他曾被称为“中老年...
9月3日消息，亚马逊的一些股东，包括持有该公司股票的一家养老基金，日前对亚马逊、其创始人贝索斯和其董事会提起诉讼，指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息，为推广自家应用，苹果现推出了一个名为“Apps by Apple”的网站，展示了苹果为旗下产品（如 iPhone、iPad、Apple Watch、Mac 和 Apple TV）开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价，引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金（Future Fund）管理合伙人加里·布莱克发帖称，降价是一种“短期麻醉剂”，会让潜在客户等待进一步降价。
据外媒9月2日报道，荷兰半导体设备制造商阿斯麦称，尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效，但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日，根据美国证券交易委员会的文件显示，苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元（约 4.65 亿元人民币）。用于在 2023-2025 年期间，发射卫星，进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道，马斯克旗下社交平台𝕏（推特）日前调整了隐私政策，允许 𝕏 使用用户发布的信息来训练其人工智能（AI）模型。新的隐私政策将于 9 月 29 日生效。新政策规定，𝕏可能会使用所收集到的平台信息和公开可用的信息，来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日，荣耀CEO赵明在采访中谈及华为手机回归时表示，替老同事们高兴，觉得手机行业，由于华为的回归，让竞争充满了更多的可能性和更多的魅力，对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能（AI）系统，该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日，非营利组织纽约真菌学会（NYMS）发出警告，表示亚马逊为代表的电商平台上，充斥着各种AI生成的蘑菇觅食科普书籍，其中存在诸多错误。
社交媒体平台𝕏（原推特）新隐私政策提到：“在您同意的情况下，我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上，各大企业都带来了最新的理念和产品，而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品，具体内容为：“以我对我‘子公司’的了解，我认为 iPhone 15 跟 iPhone 14 不会有什么区别的，除了序（列）号变了，这个‘不要脸’的东西，这个‘臭厨子’。
