物联网迎来下一个黄金十年

Uber近年来一直在使用微服务，现在Uber已经增长到大约2200个关键微服务，这个过程中Uber做了不少的权衡。Uber表示，在过去的两年中，他们尝试降低微服务的复杂性，同时仍保持微服务架构的优势。这篇文章详细介绍了Uber对微服务架构的通用方法，Uber将其称为“面向域的微服务架构”(简称：DOMA)。

面对微服务的不足，批评微服务架构的话题喧嚣尘上，但很少有用户主张完全拒绝微服务架构。因为运营收益太重要了，似乎还有针对微服务的更好替代品。Uber使用DOMA通用方法的目标是为降低总体系统复杂性，同时保持与微服务架构相关联的灵活性的企业，提供微服务向前发展的道路。

什么是微服务?

微服务是面向服务的架构的扩展。与过去大型的整体“服务”相反，微服务代表一组范围狭窄的功能的应用程序。这些应用程序是托管的，并且可以通过网络使用，并公开定义明确的接口。其他应用程序通过进行“ 远程过程调用 ”(RPC)来调用这个接口。

微服务架构的关键特征是代码的托管，调用和部署方式。如果我们考虑大型的整体应用程序，通常会将它们分为具有明确定义的接口的封装组件。这些接口将被直接称为进程内接口，而不是通过网络。通过这种方式，我们可以开始将微服务当做具有性能问题(网络I/O和序列化/反序列化)的库，以便调用其任何功能。

当我们以这种方式考虑微服务时，我们可能会思考为什么我们会完全采用微服务架构?答案通常是独立部署和扩展。对于大型的整体应用程序，企业不得不一次部署或释放所有代码。应用程序的每个新版本都可能涉及许多更改，而且部署变得既危险又费时。任何差池都可能使整个系统瘫痪。

换句话说，企业采用微服务来获得运营的价值，而以性能为代价。企业还必须承担维护支持微服务所需的基础架构的成本。事实证明，在很多情况下，这种权衡是有道理的，但这也是反对过早采用微服务架构的理由之一。

缘起

Uber采用微服务架构，因为大约在2012年至2013年，Uber拥有两个整体服务，并且微服务的使用解决了许多运营问题。

可用性风险。单一代码库中的单个回归可以使整个系统瘫痪。

风险高昂的部署。由于频繁需要回滚，因此执行这些操作很痛苦且耗时。

关注点分离差。使用庞大的代码库，很难很好地保持关注点的分离。在指数增长的环境中，权宜有时会导致逻辑和组件之间的边界不清晰。

执行效率低下。这些问题加在一起使团队难以自主或独立执行。

换句话说，随着Uber的工程师人数从10增长到100，拥有多个团队，拥有部分技术栈的整体式架构将团队的命运束缚在一起，使其难以独立运营。

Uber采用了微服务架构之后。最终，系统变得更加灵活，从而使团队更加自治。

系统可靠性。在微服务架构中，总体系统可靠性得到提高。单个服务可以关闭(并回滚)，而无需关闭整个系统。

关注点分离。在架构上，微服务架构迫使Uber提出以下问题：“为什么存在这项服务?”，从而更清楚地定义不同组件的角色。

清除所有权。谁拥有什么代码变得更加清楚。服务通常在个人，团队或企业级别拥有，从而实现更快的增长。

自主执行。独立的部署和更清晰的所有权界限，可释放各个产品和平台团队的自主执行权。

开发人员速度。团队可以独立部署代码，这使他们能够按照自己的节奏执行。

毫不夸张地说，没有微服务架构，Uber将无法实现今天维持的执行规模和执行质量。

但是，随着Uber规模的扩大，从100名工程师增加到1000名工程师，Uber开始注意到与系统复杂性大大增加相关的一系列问题。使用微服务架构，可以将单个整体的代码库换成“黑盒子”，“黑盒子”的功能可以随时更改，并且很容易导致意外的发生。



 

（编辑：阜新站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!