微服务实战：高可用与冗余策略

需积分: 10 87 浏览量更新于2024-07-18 收藏 2.51MB PDF 举报

“微服务精通 - 高级微服务：微服务基础设施与工具的实战指南” 本书深入探讨了在组织内部采用和实施冗余且高度可用的微服务所需的广泛知识。作者倾向于使用开源技术栈，并尽量减少特定编程语言的应用代码示例，以保持语言无关性。书中涉及了设计应用程序接口（API）的基本概念，如何跟踪其他服务对API的使用，以及如何文档化API。此外，还讲解了如何部署API、让其他人找到API的位置，以及如何通过分析、监控和日志记录来保持API的正常运行并设置健康警报。作者还讨论了与其他团队协作的工具和方法，以维护组织的满意度。在“高级微服务：微服务基础设施与工具的实战指南”一书中，作者Thomas Hunter II提供了实践经验，聚焦于构建微服务架构的基础设施和工具。这本书涵盖了从API设计到监控的整个生命周期，强调了实践中的问题和解决方案。通过这本书，读者可以学习到如何： 1. 设计RESTful API，遵循最佳实践，确保API的可扩展性和易用性。 2. 使用版本控制管理API，以适应不断变化的需求和兼容旧版本。 3. 实施服务发现机制，使得服务能够动态地找到和通信。 4. 配置和管理负载均衡器，确保高可用性和容错能力。 5. 使用容器化技术（如Docker）进行服务部署，提高部署的一致性和可移植性。 6. 通过持续集成和持续部署（CI/CD）流程自动化发布过程。 7. 监控服务性能，利用工具如Prometheus和Grafana收集和可视化指标。 8. 实施日志管理和分析，如使用ELK（Elasticsearch, Logstash, Kibana）堆栈。 9. 设置警报和通知系统，以便在服务出现异常时及时响应。 10. 掌握跨团队协作的工具，例如使用Git进行版本控制，Jenkins进行自动化测试，以及Confluence或Wiki进行知识共享。通过这些详细的知识点，读者将能够构建出强大、健壮且易于维护的微服务架构。无论是对于初学者还是有经验的开发者，这本书都提供了丰富的信息和实用的指导，帮助他们在这个快速发展的领域中取得成功。

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

thomas-23

粉丝: 54
资源: 8

微服务实战：高可用与冗余策略

Java之Gradle【IDEA版】入门到精通（下）（一篇文章精通系列）微服务实战项目代码

Springcloud Alibaba-2020微服务详解

Java微服务架构l零从基础到精通高清视频教程全套 163课

最新的springcloud 入门到精通

精通spring boot 42讲

springboot 从入门到精通 pdf

springboot从入门到精通

Nginx开发从入门到精通

以markdown写一份k8s从入门到精通的操作学习使用笔记手册

最新资源