微服务架构下数据库迁移策略：从关系型单一系统到分布式数据

5星 · 超过95%的资源需积分: 9 21 浏览量更新于2024-07-18 收藏 4.64MB PDF 举报

在当今的IT领域，微服务架构已经成为推动企业级应用程序灵活性和可扩展性的主要驱动力。《Migrating to Microservice Databases》一书由Edson Yanaga撰写，专为那些正在考虑从传统的关系型单体应用转向分布式数据管理的开发者和架构师提供指南。这本书的核心内容围绕着如何有效地将数据库设计模式从传统的集中式架构转换到微服务架构中。微服务架构强调的是将大型应用程序拆分成一组小型、独立的服务，每个服务都有自己的数据库。这样的设计允许团队并行开发，提高了响应速度和故障隔离性。在迁移过程中，作者首先介绍了从关系型数据库（如Oracle、MySQL或SQL Server）向分布式数据库（如NoSQL，如MongoDB、Cassandra，或者分布式关系型数据库如PostgreSQL的分片）的转变。书中详细阐述了以下几个关键知识点： 1. **评估与选择**：在决定迁移前，需要评估现有的数据库结构，确定是否适合微服务的场景。这包括对数据访问模式、事务需求和性能瓶颈的分析，以确保新架构能够满足业务需求。 2. **服务拆分与数据库分离**：根据服务边界，创建独立的数据存储单元，每个服务拥有自己的数据库，降低数据冗余和一致性问题。同时，要考虑到数据的一致性模型，如最终一致性或强一致性。 3. **API设计与数据同步**：设计清晰、一致的接口，以便服务间的数据交换。采用事件驱动的架构或消息队列技术来实现数据同步，减少实时一致性压力。 4. **数据持久化与备份**：在分布式环境中，数据持久性和备份策略变得更为复杂。需确保数据可靠地存储在各个节点，并实施适当的备份和恢复流程。 5. **监控与日志管理**：微服务架构下，需要一个强大的监控和日志系统来追踪各服务的性能，及时发现和处理潜在问题。 6. **安全与治理**：在分布式数据库中，权限管理和数据访问控制是关键，确保数据安全性和一致性。同时，要建立统一的治理框架，包括数据模型标准和版本管理。 7. **技术选型与工具**：介绍和比较不同分布式数据库技术和工具，如如何选择合适的分布式事务解决方案、数据复制机制以及数据库集群管理工具。 8. **迁移策略与计划**：提供实际操作中的迁移步骤，包括数据迁移、服务调整和测试，以确保平稳过渡。 9. **案例研究与最佳实践**：书中可能包含多个实际项目的案例分析，展示如何在不同行业和场景中成功实施微服务数据库迁移，分享最佳实践和教训。 10. **持续学习与演进**：随着技术的发展，微服务数据库领域不断更新，作者提醒读者关注最新的发展趋势和应对策略。《Migrating to Microservice Databases》是一本实用的参考书籍，不仅提供了理论指导，还为那些正在寻求从单体架构向微服务架构转型的企业和个人提供了宝贵的经验和实践指导。通过阅读本书，读者可以深入了解如何在保持业务连续性的同时，构建更加灵活、可扩展的IT基础设施。

CHAPTER 1

Introduction

Microservices certainly aren’t a panacea, but they’re a good solution

if you have the right problem. And each solution also comes with its

own set of problems. Most of the attention when approaching the

microservice solution is focused on the architecture around the code

artifacts, but no application lives without its data. And when distrib‐

uting data between different microservices, we have the challenge of

integrating them.

In the sections that follow, we’ll explore some of the reasons you

might want to consider microservices for your application. If you

understand why you need them, we’ll be able to help you figure out

how to distribute and integrate your persistent data in relational

databases.

The Feedback Loop

The feedback loop is one of the most important processes in human

development. We need to constantly assess the way that we do

things to ensure that we’re on the right track. Even the classic Plan-

Do-Check-Act (PDCA) process is a variation of the feedback loop.

In software—as with everything we do in life—the longer the feed‐

back loop, the worse the results are. And this happens because we

have a limited amount of capacity for holding information in our

brains, both in terms of volume and duration.

Remember the old days when all we had as a tool to code was a text

editor with black background and green fonts? We needed to com‐

1 The amount of time between the beginning of a task and its completion.

pile our code to check if the syntax was correct. Sometimes the com‐

pilation took minutes, and when it was finished we already had lost

the context of what we were doing before. The lead time

in this case

was too long. We improved when our IDEs featured on-the-fly syn‐

tax highlighting and compilation.

We can say the same thing for testing. We used to have a dedicated

team for manual testing, and the lead time between committing

something and knowing if we broke anything was days or weeks.

Today, we have automated testing tools for unit testing, integration

testing, acceptance testing, and so on. We improved because now we

can simply run a build on our own machines and check if we broke

code somewhere else in the application.

These are some of the numerous examples of how reducing the lead

time generated better results in the software development process.

In fact, we might consider that all the major improvements we had

with respect to process and tools over the past 40 years were target‐

ing the improvement of the feedback loop in one way or another.

The current improvement areas that we’re discussing for the feed‐

back loop are DevOps and microservices.

DevOps

You can find thousands of different definitions regarding DevOps.

Most of them talk about culture, processes, and tools. And they’re

not wrong. They’re all part of this bigger transformation that is

DevOps.

The purpose of DevOps is to make software development teams

reclaim the ownership of their work. As we all know, bad things

happen when we separate people from the consequences of their

jobs. The entire team, Dev and Ops, must be responsible for the out‐

comes of the application.

There’s no bigger frustration for developers than watching their

code stay idle in a repository for months before entering into pro‐

duction. We need to regain that bright gleam in our eyes from deliv‐

ering something and seeing the difference that it makes in people’s

lives.

2 | Chapter 1: Introduction

We need to deliver software faster—and safer. But what are the excu‐

ses that we lean on to prevent us from delivering it?

After visiting hundreds of different development teams, from small

to big, and from financial institutions to ecommerce companies, I

can testify that the number one excuse is bugs.

We don’t deliver software faster because each one of our software

releases creates a lot of bugs in production.

The next question is: what causes bugs in production?

This one might be easy to answer. The cause of bugs in production

in each one of our releases is change: both changes in code and in

the environment. When we change things, they tend to fall apart.

But we can’t use this as an excuse for not changing! Change is part

of our lives. In the end, it’s the only certainty we have.

Let’s try to make a very simple correlation between changes and

bugs. The more changes we have in each one of our releases, the

more bugs we have in production. Doesn’t it make sense? The more

we mix the things in our codebase, the more likely it is something

gets screwed up somewhere.

The traditional way of trying to solve this problem is to have more

time for testing. If we delivered code every week, now we need two

weeks—because we need to test more. If we delivered code every

month, now we need two months, and so on. It isn’t difficult to

imagine that sooner or later some teams are going to deploy soft‐

ware into production only on anniversaries.

This approach sounds anti-economical. The economic approach for

delivering software in order to have fewer bugs in production is the

opposite: we need to deliver more often. And when we deliver more

often, we’re also reducing the amount of things that change between

one release and the next. So the fewer things we change between

releases, the less likely it is for the new version to cause bugs in pro‐

duction.

And even if we still have bugs in production, if we only changed a

few dozen lines of code, where can the source of these bugs possibly

be? The smaller the changes, the easier it is to spot the source of the

bugs. And it’s easier to fix them, too.

The technical term used in DevOps to characterize the amount of

changes that we have between each release of software is called batch

DevOps | 3

2 Just make sure to follow the tool’s best practices and do not store sensitive information,

such as passwords, in a way that unauthorized users might have access to it.

size. So, if we had to coin just one principle for DevOps success, it

would be this:

Reduce your batch size to the minimum allowable size you can

handle.

To achieve that, you need a fully automated software deployment

pipeline. That’s where the processes and tools fit together in the big

picture. But you’re doing all of that in order to reduce your batch

size.

Bugs Caused by Environment

Dierences Are the Worst

When we’re dealing with bugs, we usually have log statements, a

stacktrace, a debugger, and so on. But even with all of that, we still

find ourselves shouting: “but it works on my machine!”

This horrible scenario—code that works on your machine but

doesn’t in production—is caused by differences in your environ‐

ments. You have different operating systems, different kernel ver‐

sions, different dependency versions, different database drivers, and

so forth. In fact, it’s a surprise things ever do work well in produc‐

tion.

You need to develop, test, and run your applications in develop‐

ment environments that are as close as possible in configuration to

your production environment. Maybe you can’t have an Oracle

RAC and multiple Xeon servers to run in your development envi‐

ronment. But you might be able to run the same Oracle version, the

same kernel version, and the same application server version in a

virtual machine (VM) on your own development machine.

Infrastructure-as-code tools such as Ansible, Puppet, and Chef

really shine, automating the configuration of infrastructure in mul‐

tiple environments. We strongly advocate that you use them, and

you should commit their scripts in the same source repository as

your application code.

There’s usually a match between the envi‐

ronment configuration and your application code. Why can’t they

be versioned together?

Container technologies offer many advantages, but they are partic‐

ularly useful at solving the problem of different environment con‐

4 | Chapter 1: Introduction

剩余71页未读，继续阅读

itd018

粉丝: 4

微服务架构下数据库迁移策略：从关系型单一系统到分布式数据

Migrating to Microservices Databases

Migrating to Cloud-Native App Architectures Pivotal

Migrating to Microservices

MCW-Migrating-SQL-databases-to-Azure:MCW将SQL数据库迁移到Azure

Migrating to Swift from Android

migrating to cloud native application architectures

Migrating to Cloud-Native Application Architectures

Migrating to SAP S4HANA.zip

Migrating to the Solaris Operating System The Discipline of UNIX to UNIX Migrations 2003

Migrating to MariaDB: Toward an Open Source Database Solution

最新资源