soa面向服务体系结构_服务和面向微服务的体系结构简介

soa面向服务体系结构

by Pulkit Kumar

通过Pulkit Kumar

服务和面向微服务的体系结构简介 (An introduction to service and micro-service-oriented architectures)

We’ve come a long way from the traditional three-tier monolith architecture. In order to achieve a fast, robust and scalable model of development, you might try to align your application architecture with certain philosophies and development patterns, hoping that it might make it easier to manage the team and development timelines.

与传统的三层整体架构相比，我们已经走了很长一段路。 为了实现快速，健壮和可扩展的开发模型，您可以尝试使您的应用程序体系结构与某些理念和开发模式保持一致，希望它可以使管理团队和开发时间表更加容易。

But when you actually figure out that there are so many development patterns out there that you can’t decide on any particular one because every other seems better, you might want to read this post.

但是，当您实际上发现那里有太多的开发模式以至于无法确定任何一个特定的开发模式时，因为其他每个开发模式似乎都比较好，您可能需要阅读这篇文章。

Let’s start with the basics and gain some clarity on the jargon.

让我们从基础开始，对术语有所了解。

什么是面向微服务的架构？ (What is Microservice Oriented Architecture?)

Apart from microservice being a buzzword, from the design principles of microservices, it can be simply defined as:

除了微服务成为流行语之外，从微服务的设计原理来看，它可以简单地定义为：

A highly cohesive, single purpose and decentralized service.

高度凝聚力，单一目的和分散的服务。

That is, a service which has one and only one purpose and is self-sufficient.

也就是说，一种服务只有一个目的并且是自给自足的。

Any service which matches the properties mentioned in the definition can be termed a microservice. The design principles mentioned are:

与定义中提到的属性匹配的任何服务都可以称为微服务。 提到的设计原则是：

1. Single purpose: The service should be focused on one and only one purpose. The service should be domain and goal focused. For example, a microservice can just be focused on a login mechanism.

   单一目的 ：服务应仅集中于一个目的。 服务应以领域和目标为重点。 例如，微服务可以只专注于登录机制。

2. High cohesion: The service should be self-sufficient in terms of domain requirements and domain infrastructure. The service should have all the features it needs for serving the single purpose. For example, a login microservice can have its own database.

   高内聚性 ：服务在域要求和域基础结构方面应该是自给自足的。 该服务应具有实现单一目的所需的所有功能。 例如，登录微服务可以拥有自己的数据库。

3. Decentralized: The service should be decentralized from other services and infrastructure from a logical point of view such that any changes required in the microservice should not involve changes in any other microservice. For example, a login microservice should have its own set of infrastructure components and changes required in the login microservice should not involve changes in any other microservice.

   去中心化 ：应该从逻辑角度将服务与其他服务和基础结构进行去中心化，这样微服务中所需的任何更改都不应涉及任何其他微服务中的更改。 例如，登录微服务应具有其自己的一组基础结构组件，并且登录微服务中所需的更改不应涉及任何其他微服务中的更改。

Using the microservice architecture pattern, you can split your application team into multiple teams focused on the microservice. For example, a search microservice can have its own team and a login microservice can have its own team. Both the teams can include people with expertise in the same domains such as database, frontend, and backend, given the fact that both microservices can have their own database, frontend, and backend.

使用微服务架构模式，您可以将应用程序团队划分为多个专注于微服务的团队。 例如，搜索微服务可以拥有自己的团队，而登录微服务可以拥有自己的团队。 鉴于两个微服务都可以拥有自己的数据库，前端和后端，因此这两个团队都可以包括在相同领域(例如数据库，前端和后端)具有专业知识的人员。

Pros of using microservice oriented architecture include:

使用面向微服务的架构的优点包括：

• Teams can be arranged around features/components in the product.
  可以围绕产品的功能部件/组件安排团队。

Changes in a feature/component require a change in only that particular set.

功能部件/组件的更改仅需要更改特定的集合。

• Bug pointing and localizing is easy.
  错误指向和本地化很容易。
• Symphony of domains can bring up innovative solutions.
  领域交响曲可以带来创新的解决方案。
• Managing the feature becomes easy.
  管理功能变得容易。
• More resources on a particular feature can be added if there’s a need to add some push.
  如果需要添加一些推送，则可以添加有关特定功能的更多资源。

Cons of using microservice oriented architecture include:

使用面向微服务的架构的缺点包括：

• Microservice-mesh can be an overhead to manage.
  微服务网格可能是管理的开销。
• Resourcing in terms of developers can be expensive.
  就开发人员而言，资源配置可能很昂贵。
• Teams might grow as components/features in the application do.
  团队可能会随着应用程序中组件/功能的发展而增长。
• Localization of solutions might happen if knowledge is not shared frequently across teams.
  如果团队之间不经常共享知识，则解决方案的本地化可能会发生。
• Quality of code is different across microservices.
  跨微服务的代码质量不同。

什么是面向服务的体系结构？ (What is Service Oriented Architecture?)

In a service-oriented architecture, services are divided on the basis of their role in the application layer.

在面向服务的体系结构中，服务根据其在应用程序层中的角色进行划分。

For example, database service, frontend service, backend service, etc are logical segregations of services. These services are utilized by various components of the application.

例如，数据库服务，前端服务，后端服务等是服务的逻辑隔离。 这些服务被应用程序的各个组件所利用。

Service-oriented architectures might be a better choice when the application doesn’t have a very large ecosystem of diverse features/components and components can logically share the services.

当应用程序没有非常庞大的具有不同功能部件/组件的生态系统，并且组件可以逻辑地共享服务时，面向服务的体系结构可能是更好的选择。

Using the service-oriented architecture pattern, teams can be easily split with respect to their domain expertise.

使用面向服务的架构模式，可以根据领域专业知识轻松地划分团队。

For example, teams can be simply divided into backend, devops, database, mobile, etc. If any component requires a service, the client (developing the component) will contact the service team and thus, all the core information about the service stays localized with the service team.

例如，团队可以简单地分为后端，devops，数据库，移动设备等。如果任何组件需要服务，则客户端(开发组件)将与服务团队联系，因此，有关该服务的所有核心信息均保持本地化与服务团队。

Pros of using service-oriented architecture include:

使用面向服务的体系结构的优点包括：

• Quality of code is consistent through the domain.
  在整个域中，代码质量是一致的。
• Knowledge sharing is easy within the domain.
  在领域内知识共享很容易。
• Mistakes aren’t repeated since the domain team is aware of previous failures.
  由于域团队知道以前的故障，因此不会重复犯错。
• More resources can be put on service if the need be.
  如果需要，可以投入更多资源。

Cons of using service-oriented architecture include:

使用面向服务的体系结构的缺点包括：

• Bug/break in one service can affect multiple services/layers.
  一项服务中的错误/中断可能会影响多个服务/层。
• Symphony of domains is missing due to which innovation might be lacking.
  由于缺少创新，因此缺少领域交响曲。
• Teams might end up working on only one layer if not managed properly.
  如果管理不当，团队可能最终只能在一层上工作。
• Managing multiple features is hard since it might involve changes across multiple services.
  管理多个功能很困难，因为它可能涉及跨多个服务的更改。
• One service might end up changing a lot.
  一项服务可能最终会发生很多变化。

两者有什么共同点？ (What is common in both?)

Both the development patterns differ from the traditional monolith in a significant way.

两种开发模式都与传统的整体设计有很大不同。

But both require teams and components to focus on one and only one thing.

但是，两者都要求团队和组件只专注于一件事。

Segregation and localization concepts are at the core in both the patterns. Both patterns are generally aligned with the DevOps philosophy to deliver fast growth across teams.

隔离和本地化概念是这两种模式的核心。 两种模式通常都与DevOps理念保持一致，以实现团队之间的快速增长。

结论 (Conclusion)

Since the monolith can’t serve the needs of modern and agile development, you might want to align your development practices as well as your teams with one of the two approaches.

由于整体无法满足现代敏捷开发的需求，因此您可能希望使用两种方法之一来调整开发实践以及团队。

Microservice is a buzzword these days but that doesn’t mean it the best solution to your problems.

如今，微服务已成为流行语，但这并不意味着它是解决问题的最佳解决方案。

If your application demands segregation of teams based on expertise area such as database, frontend, backend, data-science, etc, then the Service-oriented approach might be the best for you.

如果您的应用程序需要根据专业知识领域(例如数据库，前端，后端，数据科学等)将团队隔离开，那么面向服务的方法可能是最适合您的。

If your application needs many different plug-in features which require their own resources such as their own database, frontend, backend, etc, you might want to go with microservice oriented architecture and focus the teams on particular feature-sets.

如果您的应用程序需要许多不同的插件功能，这些功能需要他们自己的资源，例如他们自己的数据库，前端，后端等，那么您可能希望使用面向微服务的体系结构，并将团队集中在特定的功能集上。

However, you can also go with the hybrid approach. The hybrid approach might be useful when you’re building a platform with multiple applications.

但是，您也可以使用混合方法。 当您构建具有多个应用程序的平台时，混合方法可能会很有用。

For example, if you want to build an in-house app store, the team developing the platform (app-store/platform team) can be further divided in a service-oriented pattern; whereas the teams building apps (app-teams) can be focused and divided into microservices.

例如，如果您想建立一个内部应用商店，则开发平台的团队(应用商店/平台团队)可以进一步划分为面向服务的模式。 而构建应用程序的团队(应用程序团队)可以集中精力并分为微服务。

Sign up for my newsletter to get free access to software consulting, courses, articles, weekly-digests, and list-exclusive offers.

订阅我的时事通讯，即可免费获得软件咨询，课程，文章，每周摘要和列表独家优惠。

翻译自: https://www.freecodecamp.org/news/service-and-micro-service-oriented-architectures-explained-2f8d5da0ecdd/

soa面向服务体系结构