Nginx性能调优

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

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

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

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

面向领域的微服务架构

如果我们可以将微服务视为I / O绑定的库，而将“微服务架构”视为大型的分布式应用程序，则可以使用众所周知的架构来思考如何组织代码。

因此，“面向领域的微服务体系结构”大量借鉴了组织代码的既定方法，例如 域驱动设计 ， 清晰架构 ， 面向服务的体系架构 以及面向对象和面向接口的设计模式。 我们认为DOMA仅是创新，因为它是在大型应用的分布式系统中利用既定设计原则的相对新颖的方法。

DOMA相关的核心原理和术语如下：

1.  围绕相关微服务的集合，称为 域
2.  域的集合称之为层。域所属的层确定了允许该域内的微服务承担什么依赖性，称为 层设计
3.  为域提供接口，这些域被视为集合的单个入口点，称为 网关
4.  确定每个域都应该与其他域不可知，一个域不应该具有与其代码库或数据模型内部硬编码的另一个域相关的逻辑。由于团队经常需要在另一个团队的域中包含逻辑（例如，自定义验证逻辑或数据模型上的某些元上下文），因此我们提供了一种 扩展架构 ，以支持该域中定义明确的扩展点。

通过提供系统的体系结构，域网关和预定义的扩展点，DOMA打算将微服务体系结构从复杂的东西转变为可理解的东西：结构化的一组灵活，可重用和分层的组件。

这篇文章的其余部分将深入研究Uber在DOMA中的实施，我们已经看到的好处以及为可能希望采用这种方法的公司提供的实用建议。

Uber的措施

域

Uber域代表一个或多个与逻辑功能分组绑定的微服务的集合。设计域时常见的问题是“域应该有多大？”有些域可以包含数十个服务，有些域只能包含单个服务。重要的任务是仔细考虑每个集合的 逻辑 角色。例如，我们的地图搜索服务构成一个域，票价服务是一个域，匹配平台（匹配骑手和驾驶员）是一个域。这些也不总是遵循公司的组织结构。Uber Maps组织本身分为三个域，在三个不同的网关后面有80个微服务。

层设计

层设计回答了“什么服务可以调用其他什么服务？”的问题。在Uber的微服务架构中，我们可以将层设计视为“规模化的关注点分离”，或者，我们可以将层设计视为“规模化的依赖管理”。

层设计描述了一种机制，用于考虑Uber的故障影响范围和跨服务依赖的产品特异性。 当域从底层移到顶层时，它们在中断的情况下会影响较少的服务，并代表更多特定的产品使用案例。 相反，底层的功能具有更多的依存关系，因此趋向于具有更大的影响半径，并代表了更通用的业务功能集。下图说明了此概念。

（编辑：孝感站长网）

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