从Uber微服务看最佳实践如何炼成？

微服务特性

对于微服务没有适当的定义，你能够说它是一个框架，由小型的、独立的可部署的服务组成，执行不一样的操做。

微服务专一于单个业务领域，能够做为彻底独立的可部署服务，并在不一样的技术栈上实现它们。

在使用微服务构建本身的应用程序以前，须要清楚地了解应用程序的范围和功能。

• 解耦 - 系统内的服务在很大程度上是解耦的。所以，整个应用程序能够轻松构建，更改和缩放
• 组件化 - 微服务被视为独立的组件，能够轻松替换和升级
• 业务能力 - 微服务很是简单，专一于单一功能
• 自治 - 开发人员和团队能够独立工做，从而提升速度
• 持续交付 - 经过软件建立，测试和批准的系统自动化，容许软件的频繁发布
• 责任 - 微服务不像项目那样专一于应用程序。相反，他们将应用程序视为他们负责的产品
• 分散治理 -重点在于使用正确的工具来完成正确的做业。这意味着没有标准化模式或任何技术模式。开发人员能够自由选择最有用的工具来解决他们的问题
• 敏捷 - 微服务支持敏捷开发。任何新功能均可以快速开发并再次丢弃

微服务优点

• 独立开发 - 全部微服务均可以根据各自的功能轻松开发
• 独立部署 - 基于各自的服务，能够单独部署在任何应用程序中
• 故障隔离 - 即便应用程序的一项服务不起做用，系统仍会继续运行
• 混合技术堆栈 - 可使用不一样的语言和技术来构建同一应用程序的不一样服务
• 细粒度缩放 - 各个组件可根据须要进行扩展，无需将全部组件扩展到一块儿

微服务设计最佳实践

在当今世界，复杂性已经渗透到产品中。微服务架构可以更好地保持团队的规模和功能。

如下是微服务设计的最佳实践:

如今，让咱们来看一个用例来更好地理解微服务。

案例：购物车应用程序

当打开购物车应用程序时，你看到的只是一个网站。可是，在幕后，购物车应用程序有接受支付服务、顾客服务等等。

假设开发人员已经在一个总体框架中进行了建立。以下图:

全部功能都放在一个代码库中，并在一个底层数据库下。

如今，假设市场上出现了一个新品牌，开发人员但愿将这个品牌的全部细节都放在这个应用程序中。

他们不只要从新为新标签提供服务，还必须从新构建完整的系统并进行相应部署。

为了应对这种挑战，开发人员决定将其应用程序从单体架构转移到微服务。以下图：

这意味着开发人员没必要建立Web微服务，逻辑微服务或数据库微服务。相反，他们为搜索，推荐，客户服务等建立单独的微服务。

这种应用架构不只有助于开发人员克服之前架构面临的挑战，还有助于轻松构建，部署和扩展购物车应用程序。

推荐一个交流学习群：478030634 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

微服务设计指南

• 做为开发人员，决定构建应用程序时，要将各个域分离，并在功能上明确。
• 设计的每个微服务都只专一于应用中的一个服务。
• 确保设计的应用程序使每一个服务均可以单独部署。
• 确保微服务之间的通讯是经过无状态服务器完成的。
• 每一项服务均可以被推动到更小的服务中，拥有本身的微服务。

在设计微服务时，已经了解了基本的指导方针，如今来了解一下微服务的架构。

推荐一个交流学习群：478030634 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

微服务架构是如何工做的 ?

一个典型的微服务架构(MSA)应该包括如下组件：

1. 客户端
2. 身份提供者
3. API网关
4. 消息格式
5. 数据库
6. 静态内容
7. 管理
8. 服务发现

以下图：

这个架构看起来有点复杂，让咱们来简化一下。

一、客户端

架构始于不一样类型的客户端，从不一样的设备尝试执行各类管理功能，如搜索、构建、配置等。

二、身份提供者

这些来自客户端的请求将传递给身份提供者，这些提供者对客户端的请求进行身份验证，并将请求传递给API网关。而后，请求经过定义良好的API网关与内部服务通讯。

三、API网关

因为客户端不直接调用服务，所以API网关做为客户端将请求转发到适当的微服务的切入点。

使用API网关的优势包括:

全部服务均可以在客户端不知情的状况下进行更新。
服务也可使用非网络友好的消息传递协议。
API网关可执行跨切割功能，如提供安全性、负载均衡等。
在接收到客户端的请求后，内部架构由微服务组成，这些微服务经过消息相互通讯来处理客户端请求。

四、消息格式

有两种类型的消息经过它们进行通讯：

同步消息：在客户端等待服务响应的状况下，微服务一般倾向于使用REST (Representational State Transfer)，由于它依赖于无状态、客户端服务器和HTTP协议。这个协议被用做一个分布式环境，每一个功能都用一个资源来表示，以执行操做。
异步消息：在客户端不等待服务响应的状况下，微服务一般倾向于使用AMQP、STOMP、MQTT等协议。这些协议在这种类型的通讯中使用，由于消息的性质被定义，这些消息在实现之间能够互操做。
下一个问题是，使用微服务的应用程序如何处理数据?

五、数据处理

每一个微服务都拥有一个专有数据库来捕获它们的数据并实现相应的业务功能。此外，微服务的数据库只经过其服务API进行更新。参考下图：

微服务提供的服务被转发到任何支持不一样技术栈的进程间通讯的远程服务。

六、静态内容

在微服务内部进行通讯后，将静态内容部署到基于云的存储服务，经过内容交付网络（CDN）直接将其交付给客户端。

除了上述组件，还有一些其余组件出如今典型的微服务架构中。

七、管理

该组件负责平衡节点上的服务和故障识别。

八、服务发现

用做微服务的指南，以找到它们之间的通讯路由，由它维护节点所在的服务列表。

如今来看看这个架构的优缺点，以更好地理解什么时候使用这种架构。

微服务架构优缺点

下面来比较一下UBER以前和如今的架构。

Uber微服务案例

Uber以前的架构

像许多初创公司同样，UBER在开始之初在单一城市运营，为单一产品打造了单体架构。当时有一个代码库彷佛被清理了，并解决了UBER的核心业务问题。然而，随着UBER在全球范围内扩张，它们在可扩展性和持续集成方面面临各类各样的问题。

上图描述了UBER以前的架构。

• 与乘客和司机链接的REST API。
• 三种不一样的适配器与API一块儿使用，当预约出租车时，执行诸如帐单、付款、发送电子邮件/消息等操做。
• MySQL数据库存储全部数据。

所以，能够发现这里全部的特性，好比乘客管理、计费、通知功能、支付、行程管理和驱动管理都是在一个框架内完成的。

问题陈述

当Uber开始在世界范围扩张时，这种框架引入了各类各样的挑战。如下是一些突出的挑战。

• 全部的功能都必须从新构建、部署和测试，以更新单一功能。
• 在单个存储库中修复bug变得很是困难，由于开发人员不得不一次又一次地修改代码。
• 在全球范围内引入新功能的同时，要将这些特性进行扩展是至关困难的。

解决方案

为了不此类问题，Uber决定改变本身的架构，效仿亚马逊(Amazon)、Netflix、Twitter等其余超级增加公司。所以，Uber决定将其总体架构拆分为多个代码库，以造成一个微服务架构。

参考下面的图表，看看Uber的微服务架构。

• 咱们在这里看到的主要变化是引入了API网关，全部的司机和乘客都是经过这个网关链接的。从API网关，全部的内部点都链接在一块儿，如乘客管理、司机管理、行程管理等。
• 每一个单元是单独的可部署单元，执行单独的功能。例如：若是你想在帐单微服务中更改任何内容，那么只需部署帐单微服务，而没必要部署其余服务。
• 全部的功能都是单独扩展的，即每一个特征之间的相互依赖被移除。

例如，咱们都知道，搜索出租车的人数比预订出租车和付款的人要多。这就获得了一个推论：在乘客管理微服务上工做的流程的数量超过了处理支付的流程的数量。

经过这种方式，Uber将其架构从单一业务转移到微服务中获益。