加载中 ...

Uber改造整体单一式代码库后的微服务架构实践

2019-03-25 10:23:59 来源：沈阳软件公司作者：沈阳软件开发

　　TChannel

　　曾经对单独一个API的调用，现在可能扇出成大量对微服务的调用。为了促进在大型生态系统中发现其他服务，并找出故障点，Uber 的微服务在 Hyperbahn 上使用了开源的 TChannel ，这是一个 RPC 内部开发的网络多路复用和框架协议。TChannel 为客户端和服务器提供协议，Hyperbahn 的智能路由网将这两者连接起来。这样一来，微服务中产生的几个核心问题都得以解决：

　　服务的发现：所有生产者和使用者都注册到了路由网上，使用者可以通过名称来访问生产者，而无需知道主机或端口名。

　　容错问题：路由网络追踪类似故障率和SLA违反之类的指标，它可以检测到出现问题的主机，将其从可用的主机池中移除出去。

　　速率限制与断路器：这些功能可以确保在请求出错的情况下，或者从客户端发回的响应速度过慢的时候，不会造成级联故障。

　　Thrift

　　由于所调用服务的数量增长迅猛，很有必要为每个调用维护一个定义良好的接口。由于想用 IDL 来管理这个接口，最终我们决定了使用 Thrift。Thrift 强制服务所有者发布严格的接口定义，从而简化了服务的合成过程。不遵守接口定义的调用在 Thrift 层面上就被拒绝了。对接口公开声明的策略也强调了向后兼容的重要性，因为某个服务Thrift 接口的多个版本可能会在指定时间内同时使用。服务编写者绝对不能对接口定义作出重大修改，只能添加一些影响不大的内容，直到消费者不再使用为止。

　　为生产环境的服务联合做好准备

　　最终，在 Tincup 的实现阶段几近完成时，我们使用了一些有用的工具为生产环境做准备：

　　Hailstorm

　　首先，我们知道 Uber 的流量在每天、每周以及每年的时间中都是变化的，在我们预测的时间——比如新年年夜及万圣节时会出现流量高峰，因此我们必须在发布前确保这些服务能够处理这些增额负载。按照规定，每当在 Uber 发布新服务的时候，我们会使用内部构建的 Hailstorm 服务来加载并测试 Tincup 的端点，确定缺陷以及在压力下出现断点的地方。

　　uContainer

　　下一步我们考虑到了 Uber 工程部的另一个主要目标：更高效地使用硬件。由于 Tincup 是很轻量级的服务，可以很容易地与其他微服务共享机器，分享就是关爱不是吗？当然也并非总是如此：我们还想确保每项服务都能独立运行，不会影响在同一台机器上所运行的其他服务。为了避免这种问题出现，我们使用 uContainer（Uber 的 Docker）来执行资源隔离与限制的任务。uContainer “人”如其名，借助 Linux 的容器性能以及 Docker 来容器化 Uber 的服务。它会将某个服务打包到某个隔离的环境中，以确保无论在同一台主机上还有什么其他进程运行，这项服务都能持续运行。uContainer 在 Docker 的基础上添加了：1. 更灵活的构建功能；2. Docker 容器可见度更高的工具。

　　uDestroy

　　最后，为了迎接在生产环境中不可避免会出现的宕机及网络连接的问题，我们使用了一个内部工具uDestroy，以测试在我们控制的混乱下服务的表现——通过模拟宕机的情况，来观察系统的弹性。在定期、有目的地破坏系统的过程中，我们可以发现漏洞并不断努力提高系统的耐久性。

　　实现完成后的心得

　　通过构建 Tincup 来扩展 SOA ，我们学到了一些经验：

　　用户迁移是一项长期、缓慢的过程，因此尽可能将其简单化。提供代码实例，预测迁移完成的时间。

　　我们了解到：技术堆栈最好存在于小的服务中，Tincup 的应用逻辑非常简单，因此开发者得以集中精力来研究新的技术堆栈，而不需要将精力浪费在业务逻辑的迁移细节上。

　　一开始先开发通用单元并执行沈阳软件公司