本文共 8389 字,大约阅读时间需要 27 分钟。
soa面向服务体系结构
by Pulkit Kumar
通过Pulkit Kumar
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.
让我们从基础开始,对术语有所了解。
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:
与定义中提到的属性匹配的任何服务都可以称为微服务。 提到的设计原则是:
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.
单一目的 :服务应仅集中于一个目的。 服务应以领域和目标为重点。 例如,微服务可以只专注于登录机制。
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.
高内聚性 :服务在域要求和域基础结构方面应该是自给自足的。 该服务应具有实现单一目的所需的所有功能。 例如,登录微服务可以拥有自己的数据库。
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:
使用面向微服务的架构的优点包括:
Changes in a feature/component require a change in only that particular set.
功能部件/组件的更改仅需要更改特定的集合。
Cons of using microservice oriented architecture include:
使用面向微服务的架构的缺点包括:
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:
使用面向服务的体系结构的优点包括:
Cons of using service-oriented architecture include:
使用面向服务的体系结构的缺点包括:
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理念保持一致,以实现团队之间的快速增长。
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.
例如,如果您想建立一个内部应用商店,则开发平台的团队(应用商店/平台团队)可以进一步划分为面向服务的模式。 而构建应用程序的团队(应用程序团队)可以集中精力并分为微服务。
to get free access to software consulting, courses, articles, weekly-digests, and list-exclusive offers.
即可免费获得软件咨询,课程,文章,每周摘要和列表独家优惠。
翻译自:
soa面向服务体系结构
转载地址:http://ibewd.baihongyu.com/