深入实践：高级微服务架构与工具指南

需积分: 9 88 浏览量更新于2024-07-18 收藏 2.58MB PDF 举报

《高级微服务：实践方法论》是一本由Thomas Hunter II 所著的专业书籍，于2017年由Apress出版社发行。该书深入探讨了微服务架构的高级实践和工具链构建，旨在帮助读者理解和掌握在现代IT环境中设计、部署和管理复杂系统的微服务架构。书中内容涵盖了微服务基础设施的核心概念，包括服务拆分、通信协议、容错性、可扩展性和安全性等关键要素。作者以实际操作为导向，通过实例和案例研究，指导读者如何构建高效、可靠的微服务架构，以及如何选择和使用适合的工具来支撑微服务的开发、测试、部署和运维过程。全书不仅阐述理论，还提供了实用的步骤和策略，使读者能够将微服务的理念转化为具体项目的实施。本书特别关注的是微服务基础设施的深度，可能涉及的内容可能包括： 1. **微服务设计原则**：介绍如何根据业务需求和系统复杂性合理划分服务，确保服务边界清晰，职责单一。 2. **API和接口管理**：讲解如何设计和实现RESTful API，以及如何确保API的安全性和稳定性。 3. **服务发现与负载均衡**：探讨服务注册与发现机制，如Docker Compose、Consul或Eureka，以及如何配置负载均衡器如Nginx或Spring Cloud Load Balancer。 4. **异步处理与消息队列**：介绍如何使用消息队列（如RabbitMQ、Kafka）处理高并发和解耦场景。 5. **服务治理与监控**：涵盖了服务健康检查、故障注入、限流降级等服务治理策略，以及使用Prometheus、Zipkin等工具进行性能监控。 6. **微服务安全**：涉及认证授权、数据加密、API密钥管理和安全策略的实施。 7. **DevOps和持续集成/持续部署(CI/CD)**：探讨如何将微服务架构融入DevOps流程，利用Jenkins、GitLab CI/CD等工具自动化部署。 8. **故障恢复与容错机制**：介绍如何构建容错系统，确保即使单个服务失败，整个系统仍能保持可用性。通过阅读《高级微服务》，读者不仅可以提升微服务架构的专业技能，还能学会如何在实际项目中灵活运用各种工具和技术，从而推动组织向更加敏捷和可扩展的方向发展。这本书是一本对IT专业人士和架构师来说非常有价值的参考资源。

T. Hunter II, Advanced Microservices, DOI 10.1007/978-1-4842-2887-6_1

CHAPTER 1

Introduction

Microservice Architecture is a pattern for implementing business logic within an

organization using small, single-purpose services. This approach provides contrast to the

traditional method of building monolithic services. There are various reasons to choose

one approach instead of the other, and neither approach is absolutely better or worse

than the other.

Why Use Microservices?

Let’s look at the reasons you would want to choose to build smaller microservices instead

of a monolith as well as the counter arguments.

Forced Separation of Concerns

In a monolith, you might be tempted to create global variables and share state between

separate business logic modules, accidentally getting to the point of creating “spaghetti

code.” By separating business logic into different services, it becomes much harder to

create tangled, complex code.

The argument against this point is that a team with a lot of self-control and skill can

prevent themselves from tightly coupling two different modules of business logic within

the same codebase.

Natural Team Ownership

By separating modules of logic into separate services, it becomes easy to draw the line

and know which team owns which part of the project. With a microservice, a team

will own the entire service. Teams can control everything about the service including

deployment, monitoring, what language it is written in, and so on.

On the other hand, if a downstream service that your service relies on needs a

change, you will most likely be blocked until the owner of the other service makes the

change. If the other service is written in a different language or paradigm than what

you’re used to, there will be additional ramp-up time should you choose to contribute.

Hunting down services and their owners can be difficult if the organization doesn’t

Chapter 1 ■ IntroduCtIon

maintain a directory of service ownership. Also, bugs existing in the codebase for another

service will naturally be harder to find than bugs in the codebase of the service you

normally work with.

Frequent Deployments

By owning a small part of the overall product (in other words, a single microservice),

your team can choose when they want to deploy, perhaps even deploying several times

a day (which is referred to as continuous integration). This allows for frequent testing

of new features, A/B testing business decisions, and getting features into the hands of

customers quicker.

One of the dangers of this is the risk of “moving fast and breaking things.” Unless

you’re diligent about maintaining backward compatibility, you may release a change that

breaks an upstream consumer of your service.

Heterogeneous Selection of Languages

By separating modules of business logic into their own microservices, each service can

choose a different language or framework to be built in. This means that deep in the stack

there can be a .NET service talking to Microsoft SQL, a Java service performing some

heavy number crunching, and a Node.js service consuming both of them and generating

Hypertext Markup Language (HTML) content for end consumers. There are certainly

tools that are better suited for different problems.

Of course, every rose has its thorn. Some would argue that a company should

specialize in a single language, employing only those who are proficient in said language.

If the entire company practices Golang, then an employee could easily move from any

one team to another without needing to learn a new language.

Organization Buy-In

For an organization there are a few standards that should be adopted by all teams to make

the whole process run smoother. Try to getall of the key decision-makers into a single

room and get everyone to agree on them; this will make everyone much happier.

Throughout this book there will be numerous Collaboration Tips. Heed these tips

when you attempt to adopt standards within your organization.

Every service in your organization should have its own unique name. This name

should be represented as lowercase letters, hyphens, and if necessary numbers.

There are only two hard things in computer science: cache invalidation

and naming things.

—Phil Karlton

Chapter 1 ■ IntroduCtIon

These names will be used programmatically and will come up multiple times

throughout this book. Every log message should contain the service name. Analytic calls

should all have the name as a prefix. Discovery lookups will use this name. Every outbound

Hypertext Transfer Protocol (HTTP) request should have this name in the User-Agent header.

There should be a common place where any person in the organization can find

more information about a project, and of course this information should be searchable

using only this well-understood service name. I will cover this concept more in Chapter 8.

Separation of Concerns

How do you take a large, complex product and split it up into separate microservices? I’m

glad you asked. There is no perfect way to slice up a product, and indeed if you were to ask

ten experts to split up a product, you may get ten different answers. Let’s look at an example

organization and its products and see whether we can come up with a good approach.

At a very high level, Instagram is an app for sharing photos. Users can take a photo

and share it, adding a location, a description, and tags. Users can “like” the photos of

other users, follow users, and view a timeline of photos posted by users they follow. Users

can also search for places or tags. To become a user, a person needs to register an account

and confirm their e-mail, and all interactions require the user to be authenticated.

Nouns (Entities)

Now let’s pull out a list of important nouns from the high-level description. This list may

look like the following:

• User: A person using Instagram

• Photo: A photograph shared by a user

• Location: A real-world location

• Tag: A string to categorize photos

• Timeline: A collection of user photos over time

• E-mail: A message for confirming an account

This list can be used to define the high-level entities, which are types of data that you

need to store somewhere. With this list you know that you need to have entities named

User, Photo, Location, and Tag. E-mails are mostly ephemeral but still a type of entity.

The last one, Timeline, despite being a noun, isn’t so much an entity itself but rather a

view into a list of Photo entities.

Verbs (Actions/Relationships)

Let’s also look at some important verbs from the description.

• Share: Move a photo from a device to Instagram

• Like: A method for incrementing Internet karma

Chapter 1 ■ IntroduCtIon

• Follow: Subscribe to a particular user’s photos

• Search: Find photos based on criteria

• Register: Create a user

Each of these verbs can be thought of as an action, or a relationship, between one or

two entities. To share is to create a photo. To like is to form a relation between a user and

a photo. To follow is to relate a user and another user. To search is to list photos matching

the specified criteria. To register is to create a user. And to browse a timeline is to list

photos.

Typically you will want to have a separate service for each noun. Depending on the

complexity of the verb, it may or may not warrant its own service. Figuring out how to

separate these items becomes a science and an art. For apps such as Facebook, Twitter,

and Instagram, the timeline is frequently the most important part of an application.

Search is also an important component of many apps. Both timeline and search, which

aggregate photos for a user, can become complex enough that they would warrant their

own team and shouldn’t live inside the Photo service.

Another common concern for separating data is how to retrieve user data versus how

to authenticate a user. Authentication is something that needs to happen frequently and

universally by many services. With most apps/services, every call will contain information

about an authenticated user (such as a token). These need to be looked up quickly from

many different services. However, the User entity, with a name and preferences and an

e-mail address, probably needs to be accessed less frequently. So while user data and

authentication are coupled, it is probably a good idea to keep them separate.

E-mail is another good item to separate. Perhaps when you first build this Instagram

product, the only way to generate an e-mail is by creating an account. However, e-mail

is the kind of thing that may one day be triggered by a myriad of events. Perhaps one day

you’ll want to e-mail a user after every like they receive. With these situations in mind, it

is best to keep e-mail as its own service.

As a rule of thumb, you should be able to describe what a service does using a single

sentence, and that sentence shouldn’t contain the word and. For example, the User

service shouldn’t be described as “Manages users and e-mails account confirmation.”

Example Microservice Breakdown

Here’s a list of microservices you may arrive at for the Instagram example as well as some

of the features of that service:

• User: Register account, close account

• Authentication: Generate token from username/password

• Photo: Store photos, resize photos, remove photos

• Location: Store locations, find location by latitude/longitude

• Tag: Store tags, create tags, remove tags

Chapter 1 ■ IntroduCtIon

• Timeline: List photos

• E-mail: Send e-mail

• Search: List photos based on tags

The granularity an organization should choose for its services depends on the size

of teams and complexity of each service. As an example, Instagram will need to resize

each photo. Should this be part of the Photo service or is it worthy of its own service?

If Instagram employs a team of hardcore engineers who know how to resize images as

quickly as possible, then this function may warrant its own team.

Team Structure

Organizations which design systems … are constrained to produce designs

which are copies of the communication structures of these organizations.

—Melvin Conway

Now that I’ve described how a project can be separated into separate microservices,

it may be worth mentioning how team organization should work. Teams and services will

naturally form their own relationships. In the previous example, you may end up with a

search/timeline/photo team.

However, some services might require so much sharing of knowledge that they

should have combined ownership. You may find there’s a single user team that owns the

User, Authentication, and E-mail services.

Other microservices might be so static and simple that they simply don’t require an

entire dedicated team. In this case, you may end up with a photo attribute team that owns

the Tag and Location microservices.

Of course, you’ll want other types of teams as well. The previous examples have

included “vertical” teams. These teams own, essentially, one part of the overall product.

Each team runs pretty much autonomously and can choose whatever technologies they

want to use. It’s important to also develop “horizontal” teams that span all parts of the

product. The most common horizontal team would be that of operations (ops). This team

may be in charge of stuff that each vertical team doesn’t want to be doing or re-creating

over and over. This may include creating infrastructure, building services, managing build

servers, and so on. A common design team is also important so that the user interface of

each vertical is coherent.

Unfortunately, teams are not always easy to break apart. With Instagram, the

company needs to create both iOS and Android applications. Should there be an Android

team as well as an iOS team? Or, should each vertical have members contributing to the

Android project (e.g., the timeline team has a member or two working on the Android

timeline screen)? There is no perfect answer, and at the end of the day this question boils

down to who wants to manage what.

剩余192页未读，继续阅读

brantman

粉丝: 4
资源: 11

深入实践：高级微服务架构与工具指南

Advanced Microservices 无水印pdf

Practical Microservices Architectural Patterns pdf

Building Microservices with Spring.epub

advanced installer15.9汉化

advancedipscanner怎么使用

winccRT advanced图形库在哪里

advanced installer制作安装包

plcsim advanced 4.0下载

plcsim advanced无法启动实例

advanced ip scanner用法

最新资源