导读：Uber成长非常迅速，工程师团队快速扩充，据说Uber有2000名工程师，8000个代码仓库，部署了1000多个微服务。微服务架构是Uber应对技术团队快速增长，功能快速上线很出色的解决方案。本文偏向微服务的入门篇，以Uber微服务为例，进行了深入浅出的讲解。
对于微服务没有适当的定义，你可以说它是一个框架，由小型的、独立的可部署的服务组成，执行不同的操作。
微服务专注于单个业务领域，可以作为完全独立的可部署服务，并在不同的技术栈上实现它们。
单体架构和微服务架构区别
在使用微服务构建自己的应用程序之前，需要清楚地了解应用程序的范围和功能。
微服务特性
在当今世界，复杂性已经渗透到产品中。微服务架构能够更好地保持团队的规模和功能。
以下是微服务设计的最佳实践:
现在，让我们来看一个用例来更好地理解微服务。
案例：购物车应用程序
当打开购物车应用程序时，你看到的只是一个网站。但是，在幕后，购物车应用程序有接受支付服务、顾客服务等等。
假设开发人员已经在一个整体框架中进行了创建。如下图:
购物车应用程序的整体框架
所有功能都放在一个代码库中，并在一个底层数据库下。
现在，假设市场上出现了一个新品牌，开发人员希望将这个品牌的所有细节都放在这个应用程序中。
他们不仅要重新为新标签提供服务，还必须重新构建完整的系统并进行相应部署。
为了应对这种挑战，开发人员决定将其应用程序从单体架构转移到微服务。如下图：
购物车应用程序的微服务架构
这意味着开发人员不必创建Web微服务，逻辑微服务或数据库微服务。相反，他们为搜索，推荐，客户服务等创建单独的微服务。
这种应用架构不仅有助于开发人员克服以前架构面临的挑战，还有助于轻松构建，部署和扩展购物车应用程序。
在设计微服务时，已经了解了基本的指导方针，现在来了解一下微服务的架构。
一个典型的微服务架构(MSA)应该包括以下组件：
如下图：
微服务架构
这个架构看起来有点复杂，让我们来简化一下。
1、客户端
架构始于不同类型的客户端，从不同的设备尝试执行各种管理功能，如搜索、构建、配置等。
2、身份提供者
这些来自客户端的请求将传递给身份提供者，这些提供者对客户端的请求进行身份验证，并将请求传递给API网关。然后，请求通过定义良好的API网关与内部服务通信。
3、API网关
由于客户端不直接调用服务，因此API网关作为客户端将请求转发到适当的微服务的切入点。
使用API网关的优点包括:
在接收到客户端的请求后，内部架构由微服务组成，这些微服务通过消息相互通信来处理客户端请求。
4、消息格式
有两种类型的消息通过它们进行通信：
下一个问题是，使用微服务的应用程序如何处理数据?
5、数据处理
每个微服务都拥有一个专有数据库来捕获它们的数据并实现相应的业务功能。此外，微服务的数据库只通过其服务API进行更新。参考下图：
微服务处理数据演示
微服务提供的服务被转发到任何支持不同技术栈的进程间通信的远程服务。
6、静态内容
在微服务内部进行通信后，将静态内容部署到基于云的存储服务，通过内容交付网络（CDN）直接将其交付给客户端。
除了上述组件，还有一些其他组件出现在典型的微服务架构中。
7、管理
该组件负责平衡节点上的服务和故障识别。
8、服务发现
用作微服务的指南，以找到它们之间的通信路由，由它维护节点所在的服务列表。
现在来看看这个架构的优缺点，以更好地理解何时使用这种架构。
| 微服务架构的优点 | 微服务架构的缺点 |
|---|---|
| 自由使用不同的技术 | 增加故障排除难题 |
| 每个微服务都关注单一业务能力 | 由于远程呼叫而增加延迟 |
| 支持单独的可部署单元 | 增加配置和其他运营工作量 |
| 允许频繁的软件发布 | 难以保持交易安全 |
| 确保每项服务的安全性 | 很难跟踪各种服务边界的数据 |
| 并行开发和部署多个服务 | 服务之间很难移动代码 |
下面来比较一下UBER之前和现在的架构。
Uber之前的架构
像许多初创公司一样，UBER在开始之初在单一城市运营，为单一产品打造了单体架构。当时有一个代码库似乎被清理了，并解决了UBER的核心业务问题。然而，随着UBER在全球范围内扩张，它们在可扩展性和持续集成方面面临各种各样的问题。
UBER的单体架构
上图描述了UBER之前的架构。
因此，可以发现这里所有的特性，比如乘客管理、计费、通知功能、支付、行程管理和驱动管理都是在一个框架内完成的。
问题陈述
当Uber开始在世界范围扩张时，这种框架引入了各种各样的挑战。以下是一些突出的挑战。
解决方案
为了避免此类问题，Uber决定改变自己的架构，效仿亚马逊(Amazon)、Netflix、Twitter等其他超级增长公司。因此，Uber决定将其整体架构拆分为多个代码库，以形成一个微服务架构。
参考下面的图表，看看Uber的微服务架构。
Uber的微服务架构
例如，我们都知道，搜索出租车的人数比预订出租车和付款的人要多。这就得到了一个推论：在乘客管理微服务上工作的流程的数量超过了处理支付的流程的数量。
通过这种方式，Uber将其架构从单一业务转移到微服务中获益。
原文链接：
原文：https://www.cnblogs.com/justBobo/p/10660408.html