微服务设计模式：实战与策略

3星 · 超过75%的资源需积分: 35 131 浏览量更新于2024-07-19 1 收藏 4.54MB PDF 举报

"《Microservice Patterns》是关于微服务设计模式的一本书，涵盖了从单体应用转型、微服务分解策略到生产环境中微服务的实施等多个关键主题。作者旨在为希望采用微服务架构的企业开发者和架构师提供中级水平的指导。书中强调了微服务并非万能解决方案，它既有优势也有挑战，并探讨了在实际使用中需要解决的问题。" 本书分为多个章节，详细讲解了以下知识点： 1. **逃离单体地狱**：这一部分讨论了单体应用的局限性以及为何需要转向微服务架构，包括单体应用的扩展性问题、维护困难和敏捷开发的挑战。 2. **分解策略**：介绍了如何将大型系统拆分成微服务，包括基于业务能力、领域驱动设计（DDD）以及其它有效的分解方法。 3. **微服务间的进程通信**：探讨了RESTful API、消息队列、gRPC等不同通信方式的优缺点，以及如何选择合适的通信机制。 4. **使用Saga管理事务**：解释了在分布式系统中实现跨服务事务的Saga模式，包括其工作原理和实现策略。 5. **在微服务架构中设计业务逻辑**：这部分讲述了如何在微服务中设计和实现复杂的业务流程，确保服务之间的协作和数据一致性。 6. **事件溯源**：介绍了事件溯源作为一种开发业务逻辑的方法，以及如何利用事件流来构建可持久化的业务状态。 7. **实现查询服务**：讨论了在微服务架构中处理查询操作的最佳实践，如读写分离、CQRS（命令查询职责分离）以及视图模型的构建。 8. **外部API模式**：讲解了设计健壮且安全的微服务API，包括API网关、版本控制、认证和授权等关键话题。 9. **测试微服务**：涵盖了微服务测试的挑战，如隔离测试、端到端测试和持续集成/持续部署（CI/CD）策略。 10. **微服务生产实践**：讨论了监控、日志、故障排查以及微服务架构在生产环境中的部署和运维。 11. **向微服务的重构**：提供了从单体应用向微服务架构逐步演进的策略和技巧，包括拆分过程和风险管理。通过阅读这本书，读者可以深入了解微服务架构的全貌，学习如何在实践中有效地设计和实施微服务，以应对复杂的企业级软件开发挑战。同时，书中也提醒读者注意微服务可能带来的复杂性和运维难题，以便在选择技术路径时做出明智的决策。

The decomposed application consists of numerous front-end and backend services. The

front-end services include an API gateway and the Restaurant Web UI. The API

gateway, which plays the role of a facade and is described in detail in chapter XYZ,

provides the REST APIs that are used by the consumers' and couriers' mobile

applications. The Restaurant Web UI implements the web interface that is used by the

restaurants to manage menus and process orders. The backend services include Order

management and Delivery management. They are mostly the same modules that were

described at the start of this chapter. We have turned many of the application’s main

modules into standalone services.

1.3.3 Isn’t the microservice architecture the same as SOA?

Some critics of the microservice architecture claim that it is nothing new and that it is

just SOA. At a very high-level, there are some similarities. SOA and the microservice

architecture are architectural styles that structure a system as a set of services. But once

you dig deep you encounter significant differences.

SOA and the microservice architecture usually use different technology stacks. SOA

applications typically use heavyweight technologies such as SOAP and other WS*

standards. They often use a ESB to integrate the services. Applications built using the

microservice architecture tend to use lightweight, open-source technologies such as a

REST. The services talk directly to each other without using ESB to mediate

communication.

SOA and the microservice architecture also differ in how they treat data. SOA

applications typically have a global data model and share databases. In contrast, as

mentioned earlier, in the microservice architecture each service has it’s own database.

Moreover, as we describe in chapter XYZ, each service is usually considered to have

its own domain model.

Another key difference between SOA and the microservice architecture is the size of

the services. SOA is typically used to integrate large, complex monolithic applications.

While services in a microservice architecture are not always tiny they are almost

always much smaller. As a result, a SOA application will usually consist of a few large

services where is a microservices-based application will consist of 10s or 100s of

smaller services.

1.4 Benefits of microservices

The microservice architecture has a number of benefits. First, each service is relatively

small. The code is easier for a developer to understand. The small code base doesn’t

slow down the IDE making developers more productive. Also, each service typically

starts a lot faster than a large monolith, which again makes developers more

productive, and speeds up deployments

Second, each service can be deployed independently of other services. If the

developers responsible for a service need to deploy a change that’s local to that service

they do not need to coordinate with other developers. They can simply deploy their

©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and

other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.

https://forums.manning.com/forums/microservice-patterns

Licensed to rong fengliang <1141591465@qq.com>

changes. A microservice architecture makes continuous deployment feasible.

Third, each service can be scaled independently of other services using X-axis cloning

and Z-axis partitioning. Moreover, each service can be deployed on hardware that is

best suited to its resource requirements. This is quite different than when using a

monolithic architecture where components with wildly different resource requirements

– e.g. CPU intensive vs. memory intensive – must be deployed together.

The microservice architecture makes it easier to scale development. You can organize

the development effort around multiple, small (e.g. two pizza) autonomous, teams.

Each team is solely responsible for the development and deployment of one or more

related services. Each team can develop, deploy and scale their services independently

of all of the other teams.

The microservice architecture also improves fault isolation. For example, a memory

leak in one service only affects that service. Other services will continue to handle

requests normally. In comparison, one misbehaving component of a monolithic

architecture will bring down the entire system.

Last but not least, the microservice architecture eliminates any long-term commitment

to a technology stack. In principle, when developing a new service the developers are

free to pick whatever language and frameworks are best suited for that service. Of

course, in many organizations it makes sense to restrict the choices but the key point is

that you aren’t constrained by past decisions.

Moreover, because the services are small, it becomes practical to rewrite them using

better languages and technologies. It also means that if the trial of a new technology

fails you can throw away that work without risking the entire project. This is quite

different than when using a monolithic architecture, where your initial technology

choices severely constrain your ability to use different languages and frameworks in

the future.

1.5 Drawbacks of microservices

Of course, no technology is a silver bullet, and the microservice architecture has a

number of significant drawbacks and issues. Indeed most of this book is about how to

address the drawbacks and issues of the microservice architecture. As you read about

the challenges don’t worry - later on, I’ll describe ways to address them.

One challenge with using the microservice architecture is that there isn’t a concrete,

well-defined algorithm for decomposing a system into services. Like much of software

development, it is some what of an art. To make matter’s worse, if you decompose a

system incorrectly you will build a distributed monolith, a system consisting of

coupled services that must be deployed together. It has the drawbacks of both the

monolithic architecture and the microservice architecture.

Another challenge with using the microservice architecture is that developers must deal

with the additional complexity of creating a distributed system. Developers must use

an inter-process communication mechanism. Implementing use cases that span

©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and

other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.

https://forums.manning.com/forums/microservice-patterns

Licensed to rong fengliang <1141591465@qq.com>

multiple services requires the use of unfamiliar techniques. IDEs and other

development tools are focused on building monolithic applications and don’t provide

explicit support for developing distributed applications. Writing automated tests that

involve multiple services is challenging. These are all issues that are specific to the

microservice architecture.

The microservice architecture also introduces significant operational complexity. There

are many more moving parts – multiple instances of different types of service – that

must be managed in production. To do this successfully you need a high-level of

automation, either home-grown code or a PaaS-like technology such as Netflix

Spinnaker and related components, or an off the shelf PaaS such as Pivotal Cloud

Foundry or one of the Docker orchestration platforms.

Also, deploying features that span multiple services requires careful coordination

between the various development teams. You have to create a rollout plan that orders

service deployments based on the dependencies between services. That’s quite

different than when using a monolithic architecture where you can easily deploy

updates to multiple components atomically.

Another challenge with using the microservice architecture is deciding at what point

during the lifecycle of the application you should use this architecture. When

developing the first version of an application, you often do not have the problems that

this architecture solves. Moreover, using an elaborate, distributed architecture will

slow down development.

This can be a major dilemma for startups whose biggest challenge is often how to

rapidly evolve the business model and accompanying application. Using the

microservice architecture might make it much more difficult to iterate rapidly. Later

on, however, when the challenge is how to scale and you need to use functional

decomposition, then tangled dependencies might make it difficult to decompose your

monolithic application into a set of services.

Because of these issues, adopting a microservice architecture should not be undertaken

lightly. However, for complex applications, such as a consumer-facing web application

or SaaS application, it is usually the right choice. Well known sites such as eBay

[PDF], Amazon.com, Groupon, and Gilt have all evolved from a monolithic

architecture to a microservice architecture.

As you can see, the microservice architecture has many benefits but it is also has some

significant drawbacks. There are numerous issues that you must address when using

the microservice architecture. Moreover, many of these issues have multiple solutions,

each with a different set of trade-offs. There is no one single perfect solution. In order

to guide your decision making I’ve created the Microservice Architecture pattern

language. I’ll reference this pattern language throughout the rest of the book as I teach

you about the microservice architecture. Let’s look at what is a pattern language and

why it is helpful.

©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and

other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.

https://forums.manning.com/forums/microservice-patterns

Licensed to rong fengliang <1141591465@qq.com>

1.6 Microservice architecture pattern language

Architecture and design is all about making decisions. You need to decide whether the

monolithic or microservice architecture is the best fit for your application. And, then if

you pick the microservice architecture there are lots of issues that you need to address.

When making these decisions there are lots of tradeoffs to consider. A good way to

describe the various architectural and design options and improve decision making is to

use a pattern language. Let’s first look at why we need patterns and a pattern language.

After that we will take a tour of the microservice architecture pattern language.

1.6.1 Microservices are not a silver bullet

Back in 1986, Fred Brooks, author of The Mythical Man-Month, said that in software

engineering, there are no silver bullets. In other words, there are no techniques or

technologies that if you adopted would give you a 10X boost in productivity. Yet 30

years later, developers are still arguing passionately about their favorite silver bullets,

absolutely convinced that their favorite technology will give them a massive boost in

productivity.

A lot of arguments follow the Suck/Rock dichotomy, which is a term coined by Neil

Ford. They often have this structure: If you do X then a puppy will die so, therefore,

you must do Y. For example, synchronous vs. reactive programming, object-oriented

vs. functional, Java vs. JavaScript, REST vs messaging. Of course, reality is much

more nuanced. No technology is a silver bullet. Every technology has drawbacks and

limitations, which are often overlooked by its advocates. As a result, the adoption of a

technology usually follows the Gartner hype cycle.

Microservices are not immune to the silver bullet phenomenon. Whether this

architecture is appropriate for your application depends on a lot of factors.

Consequently, it is bad advice to say to always use the microservice architecture. But

conversely, it is equally bad advice to say never use them. Like many things, it

depends!

The underlying reason for these polarized and hyped arguments about technology is

that humans are primarily driven by their emotions. Jonathan Haidt in his excellent

book The Righteous Mind: Why Good People Are Divided by Politics and Religion

uses the metaphor of an elephant and its rider to describe how the human mind works.

The elephant represents the emotion part of the human brain. It makes most of the

decisions. The rider represents the rational part of the brain. It can sometimes influence

the elephant but it mostly provides justifications for the elephant’s decisions.

We—as in the software development community—need to overcome our emotional

nature and find a better way of discussing and applying technology. A great way to

discuss and describe technology is to use the pattern format.

1.6.2 What is a pattern?

A pattern is a "reusable solution to a problem that occurs in particular context". This is

already a major improvement because it introduces the idea of a context. Thinking

other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.

https://forums.manning.com/forums/microservice-patterns

Licensed to rong fengliang <1141591465@qq.com>

about the context of a problem is important because, for example, a solution that solves

the problem at the scale of Netflix might not be the best approach for an application

with fewer users.

The value of patterns goes far beyond requiring you to consider the context of a

problem. They force you to consider other critical yet frequently overlooked aspects of

a solution. A commonly used pattern structure includes three especially valuable

sections: forces, resulting context, and related patterns.

Forces

The forces section describes the issues that you must address when solving a problem

in a given context. Forces can conflict so it might not be possible to solve all them.

Which forces are more important depends on the context. You have to prioritize

solving some forces over others. For example, code must be easy to understand and

have good performance. Code written in a reactive style has better performance than

synchronous code, yet is often more difficult to understand. Explicitly listing the forces

is useful because it makes it clear what issues need to be solved.

Resulting context

The resulting context section describes the consequences of applying the pattern. It

consists of three parts:

• benefits - the benefits of the pattern including the forces that have been resolved

• drawbacks - the drawbacks of the pattern including the unresolved forces

• issues - the new problems that have been introduced by applying the pattern.

The resulting context provides a more complete and less biased view of the solution,

which enables better design decisions.

Related patterns

The related patterns section describes the relationship between this pattern and other

patterns. There are three types of relationships between patterns

• Predecessor - a predecessor pattern is a pattern that motivates the need for this

pattern. For example, the Microservice Architecture pattern is the predecessor to

the rest of the patterns in the pattern language except the monolithic architecture

pattern.

• Successor - a pattern that solves an issue that is introduced by this pattern. For

example, if you apply the Microservice Architecture pattern you must then apply

numerous successor patterns including service discovery patterns and the Circuit

Breaker pattern.

• Alternative - a pattern that provides an alternative solution to this pattern. For

example, the Monolithic Architecture pattern and the Microservice Architecture

pattern are alternative ways of architecting an application. You pick one or the

other.

The explicit description of related patterns provides valuable guidance on how to

other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.

https://forums.manning.com/forums/microservice-patterns

Licensed to rong fengliang <1141591465@qq.com>

剩余157页未读，继续阅读

荣锋亮

粉丝: 3
资源: 11

微服务设计模式：实战与策略

Microservice Patterns - With examples in java - first version

Concurrent Patterns and Best Practices

microservices-design-patterns：使用多种语言的微服务架构

!pip install mlxtend from mlxtend.preprocessing import TransactionEncoder from mlxtend.frequent_patterns import apriori from mlxtend.frequent_patterns import association_rules爆红，怎么解决

mlxtend.frequent_patterns

mlxtend.frequent_patterns是什么

ds 模型传递算法代码

collected, slice_weights = 0, [] for __, s in SLICES_INFO.items(): collected += s['client_weight'] slice_weights.append(collected) collected, mb_weights = 0, [] for __, mb in MOBILITY_PATTERNS.items(): collected += mb['client_weight'] mb_weights.append(collected)

最新资源