高级微服务：实战微服务基础设施与工具

需积分: 2 59 浏览量更新于2024-07-18 收藏 5.11MB PDF 举报

"Advanced Microservices - A Hands-on Approach to Microservice Infrastructure and Tooling" by Thomas Hunter II 本书深入探讨了在组织内部采用和实施冗余且高可用的微服务架构的知识。作者倾向于使用开源技术栈来构建微服务。尽管书中包含了一些应用代码示例，但重点在于提供对微服务基础设施和工具的全面理解。微服务是一种现代软件开发方法，它提倡将大型应用程序分解为一组小型、独立的服务，每个服务都能在其自己的进程中运行，与其它服务通过轻量级通信机制（如HTTP/REST API）进行交互。这种架构允许团队并行开发、部署和扩展服务，提高了系统的可伸缩性和灵活性。书中可能涵盖了以下关键知识点： 1. **微服务设计原则**：包括单一职责原则（SRP）、服务边界定义、接口契约设计以及服务间的通信机制。 2. **服务发现**：讨论如何使用像Consul或Eureka这样的服务发现工具，让服务能够动态地找到彼此。 3. **容器化与Docker**：介绍如何使用Docker容器化微服务，以便于部署和隔离服务环境。 4. **编排工具Kubernetes和Docker Swarm**：探讨如何使用这些工具来管理和服务的生命周期，包括自动扩展、负载均衡和故障恢复。 5. **持续集成/持续部署(CI/CD)**：讲解如何构建CI/CD流水线，确保快速、可靠地发布新版本服务。 6. **数据管理**：涉及分布式数据库、事件驱动架构以及数据一致性解决方案，如CQRS（命令查询责任分离）和Event Sourcing。 7. **安全性**：讨论API网关、身份验证、授权以及微服务之间的安全通信。 8. **监控与日志**：介绍使用Prometheus、Grafana等工具进行性能监控，以及ELK（Elasticsearch, Logstash, Kibana）堆栈的日志管理。 9. **测试策略**：包括单元测试、集成测试和端到端测试在微服务架构中的应用。 10. **故障隔离和弹性**：探讨如何设计系统以应对失败，实现服务间的解耦和容错能力。通过这本书，读者可以期待获得实际操作经验，学习如何构建一个健壮的微服务架构，并了解如何选择和使用适合的开源工具来支持这个架构。书中提供的案例研究和实战技巧将帮助读者在实际工作中更好地应用微服务理念和技术。

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页未读，继续阅读

alex6801

粉丝: 63
资源: 64

高级微服务：实战微服务基础设施与工具

Advanced Microservices 无水印pdf

sample-spring-microservices-advanced：Spring Boot和Spring Cloud Microservices的更高级示例，显示了诸如Zuul上的api Swagger2，与MongoDB集成，配置服务器，与Spring Cloud Contract或Hoverfly进行测试等工具的用法

testing java microservices

Practical Microservices Architectural Patterns - Event-Based Java Microservices

Practical Microservices Architectural Patterns pdf

Practical Microservices Architectural Patterns.pdf

Building Microservices with Spring.epub

java-ee-8-microservices.rar

Developing-Microservices-with-Node-js.pdf

microservice-crutch:使用 medseek-util-microservices+AMQP 轻松编写微服务

最新资源