说说反射的用途及实现？

由于这些缺点，近年来也有一些批评微服务架构的声音，但是却很少有人主张彻底拒绝微服务架构。运营收益太重要了，而且似乎没有有效的替代方案。我们介绍DOMA的目的是为了给那些希望降低整体系统复杂性，同时又保持微服务架构相关灵活性的组织提供一些经验建议。

这篇文章主要解释了什么是DOMA，以及Uber采用这种架构的原因，它对平台和产品团队带来哪些好处。最后，给想要采用这种架构的团队一些建议。

什么是微服务

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

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

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

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

动机

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

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

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

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

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

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

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

（编辑：孝感站长网）

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