微服务架构为何这么流行？

微服务是面向服务架构的延伸。与2000年代相当大的 "服务 "相比，微服务是代表一组小型功能的应用程序。这些应用通过网络托管，并暴露出一个明确定义接口。其他应用程序通过进行远程过程调用（RPC）方式来调用这个接口。

微服务架构的特点是代码的托管、调用和部署方式。比如大型的单体应用，它们通常会被分割成具有明确定义接口的封装组件。然后，这些接口就可以直接在进程中调用，而不是通过网络。通过这种方法，我们将微服务看作一个性能受到影响的库（网络I/O和序列化/反序列化），以便调用它的任何功能。

当我们以这种方式来思考微服务时，可能会质疑为什么我们会采用微服务架构。答案通常是独立部署和扩展。对于一个大型的单体应用程序，应用被迫一次性部署或发布所有的代码。应用程序的每一个新版本都可能涉及许多更改。部署变得风险大、耗时长。任何人都可以使整个系统瘫痪。

换句话说，业务采用微服务是以牺牲性能为代价来获取运营利益。业务还必须承担维护支持微服务所需的基础设施的成本。事实证明，在很多情况下，这种权衡是很有意义的，但这也是反对过早采用微服务架构的有力论据。

在Uber，我们也采用了微服务架构，因为我们（大约在2012-2013年）主要有两个单体服务，遇到了很多通过微服务来解决的运营问题。

•  可用性风险。单体代码库内的一次回滚就会使整个系统（在本例中是Uber的全部）瘫痪。
•  部署风险大，成本高。在需要频繁回滚的情况下，执行这些操作既困难又耗时。
•  不平滑的关注点分离。在庞大的代码库中，很难保持良好的关注点分离。尤其在一个指数级增长的环境中，权宜之计有时会导致逻辑和组件之间的界限不清。
•  执行效率低下。这些问题加在一起，使得团队很难独立自主地执行任务。
•  

随着Uber从10多个工程师发展到100多个工程师，多个团队拥有技术栈的碎片时，这种单一的架构将团队的命运捆绑在一起，使得独立运作变得困难。

因此，我们采用了微服务架构。最终，我们的系统变得更加灵活，这使得团队能够更加自主。

•  系统的可靠性。在微服务架构中，整体系统的可靠性上升。单个服务可以在不影响整个系统的情况下宕机（并被回滚）。
•  关注点的分离。从架构上来看，微服务架构迫使你去问 "这个服务为什么存在？"更加清晰地定义不同组件的角色。
•  明确所有权。代码拥有者变得更加清楚。服务通常由个人、团队或组织级别拥有，从而实现更快的增长。
•  自主执行。独立的部署 更清晰的所属权限，让不同的产品和平台团队能够自主执行。
•  开发人员的速度。应用团队可以独立部署他们的代码，这使得他们能够按照自己的项目进度来执行

毫不夸张地说，如果没有微服务架构，Uber不可能达到今天所保持的规模和执行质量。

然而，随着公司规模的进一步扩大，从100多名工程师到1000多名工程师，我们开始注意到一系列与系统复杂性大大增加的相关问题。在微服务架构下，人们用单一的整体代码库换取了黑盒，黑盒的功能随时可能发生变化，很容易造成意外情况。

例如，工程师们不得不通过12个不同团队大约50个服务来调查问题的根本原因。

理解服务之间的依赖关系可能会变得相当困难，因为服务之间的调用可能会深入许多层。第n个依赖关系的延迟峰值可能会导致上游的一连串问题。如果没有合适的工具，就不可能看到实际发生的情况，这让调试变得困难。

为了构建一个简单的功能，工程师往往需要跨多个服务工作，所有这些服务都由不同的个人和团队所拥有。这就需要跨部门跨团队的合作，在会议、设计和代码审查上花费时间。由于团队在彼此的服务中构建代码，修改彼此的数据模型，甚至代表服务所有者执行部署，早期对服务所有权的明确界限划分受到了影响。网络化的单体可能会形成，看似独立的服务都必须一起部署才能安全地执行任何变更。

这样所带来的结果就是开发进度变慢、服务所属不稳定、迁移更困难等。对于已经采用微服务架构的企业来说，已经没有回头路了。这就变成了 "有了它们不能活，没有它们不能活"。

（编辑：应用网_丽江站长网）

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