.NET Core微服务探索指南

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

"Exploring .NET Core with Microservices" 本文将深入探讨如何利用.NET Core构建微服务架构的应用程序。.NET Core是微软推出的一款开源、跨平台的开发框架，它允许开发者在Windows、Linux和macOS等操作系统上创建高效、高性能的应用。微服务是一种软件架构模式，它提倡将单一应用程序划分为一组小的、独立的服务，每个服务都运行在其自身的进程中，且拥有自己的数据库，从而提高可伸缩性、可维护性和可部署性。 ASP.NET Core是.NET Core框架的一部分，专门用于构建Web应用程序和服务。它是对传统ASP.NET的重大升级，提供了更轻量级、高性能的开发体验。ASP.NET Core支持跨平台开发，可以用来创建RESTful API、Web应用以及基于WebSocket的实时应用。 Entity Framework Core（EF Core）是.NET Core下的一个开源对象关系映射（ORM）框架，它简化了数据库与应用程序之间的交互。通过EF Core，开发者可以用面向对象的方式来处理数据，而无需关注底层SQL语句，提高了开发效率。它支持多种数据库系统，如SQL Server、SQLite、MySQL等，并且具有良好的可扩展性，允许自定义数据库提供程序。在本书"Exploring .NET Core with Microservices"中，作者Dustin Metzgar将引导读者了解如何利用这些技术来设计和实现微服务架构。读者将学习如何： 1. **理解微服务架构**：包括其核心原则、优点和挑战，以及如何根据业务需求来划分服务。 2. **掌握ASP.NET Core**：学习如何创建API端点，配置中间件，以及如何实现身份验证和授权。 3. **运用EF Core**：学习如何设计实体模型，使用数据库迁移，以及进行高效的数据查询。 4. **容器化和Docker**：了解如何使用Docker来封装和部署.NET Core微服务，以实现跨平台和隔离性。 5. **服务发现和注册**：探讨如何使用服务发现工具（如Consul或Eureka）来定位和协调微服务实例。 6. **测试和监控**：学习单元测试、集成测试的方法，以及如何设置日志和性能监控，确保微服务的稳定运行。 7. **持续集成/持续部署(CI/CD)**：理解如何配置CI/CD管道，如使用Jenkins或Azure DevOps，以自动化构建、测试和部署过程。 8. **扩展性和容错**：研究如何设计和实现服务的水平扩展，以及如何利用负载均衡和断路器模式提高系统的健壮性。通过本书，开发者不仅可以深入了解.NET Core、ASP.NET Core和EF Core，还能获得实践微服务架构所需的各种技能，从而能够构建出可扩展、健壮且易于维护的现代应用程序。

11Common legacy code traits and refactorings

Imagine that you maintain World of RuneQuest, an online fantasy RPG. You’re

planning to start development on a new version of the game, but recently you’ve

noticed that the code has become bloated and disorganized, and development veloc-

ity has dropped as a result. You want to give the

codebase a thorough spring clean

before you start developing the new version. Let’s look at some areas you could tackle.

4.2.1 Stale code

Stale code is any code that remains in the codebase even though it’s no longer

needed. Deleting this unneeded code is one of the easiest, safest, and most satisfying

refactoring tasks you can hope for. Because it’s so easy, it’s often a good way to warm

up before embarking on more serious refactoring.

Removal of stale code has a number of benefits:

 It makes the code easier to understand, because there’s now less code to read.

 It reduces the chance of somebody wasting time on fixing or refactoring code

that isn’t even used.

 As a satisfying bonus, every time you delete some code, the project’s test cover-

age increases.

Stale code can be divided into a few categories.

COMMENTED-OUT CODE

This is the lowest of all low-hanging fruit. If you see a block of code that has been com-

mented out, don’t think twice, just delete it! There’

s absolutely no reason to leave

commented-out code lying around. It’s often left deliberately as a record of how the

code was changed, but that’s exactly what the version control system is for. It’s point-

less noise, making the surrounding

code more difficult to read.

DEAD CODE

Dead code is any code in your software that will definitely never be executed. It might

be a variable that’s never used, a branch of an

statement that’s never taken, or even

a whole package of code that’s never referenced.

In the following simple exam

ple of dead code, the

armorStrength

variable can

never have a value greater than 7, so it’s always less than 10 and the

else

block will

never run. It’s dead code and thus can and should be removed.

int armorStrength = 5;

if (player.hasArmorBoost()) {

armorStrength += 2;

}

...

if (armorStrength < 10) {

Armor strength is always 7 or less,

so this branch will always run.

defenceRatio += 0.1;

} else {

defenceRatio += 0.2;

This branch is dead code.

}

Licensed to UNKNOWN UNKNOWN <Eugenecheng10@gmail.com>

12 CHAPTER 4 Refactoring

There are many tools that can help you find and remove dead code from your code-

base. Most

IDEs will point out fields, methods, and classes that aren’t referenced, and

tools such as FindBugs (discussed in chapter 2) also include relevant rules.

ZOMBIE CODE

Some code that’s actually dead may look very much alive. I call this zombie code. Its

liveliness (or lack of) is impossible to discover just from reading the surrounding

source. Examples include

 Code that branches based on data received from an external source such as a

database, in which some of the branches are never triggered

 Pages of a website or screens of a desktop application that are no longer linked

from anywhere

As an example of the first point, let’s alter th

e previous code sample so that the value

armorStrength

is read from a DB. Just by reading the code, you have no idea what

value

armorStrength

might have, so the code looks alive and reasonable.

int armorStrength = DB.getArmorStrength(play.getId());

...

if (armorStrength < 10) {

defenceRatio += 0.1;

} else {

defenceRatio += 0.2;

Is this branch dead or alive?

}

But when you look at the actual data in the DB, you might find that all 5 million play-

ers have an armor strength of less than 10, so in fact the

else

will never run.

In this case, you should check all the places that are setting this value in the

DB (to

make sure that a strength of 10 or more is impossible), and then add a

DB constraint

to act as documentation for your understanding of the model, before finally deleting

the unneeded

else

block.

In the case of pages or screens that aren’

t linked from anywhere, it’s often difficult

and time-consuming to confirm that a given page of a web application is dead. Even if

there are no links to it, users might still be accessing it directly, perhaps via browser

bookmarks, so you may have to trawl through web server access logs to check that the

page is safe to delete.

I was affected by a real-world example of zombie

code when I joined a team that

maintained a large legacy web application. Before I joined the team, they’d been

A/B

testing a major update to the site’s top page. There were two separate versions of the

page, and users were directed to one or the other based on a per-user flag in the

DB.

Little did I know, the

A/B test had already finished (the flags in the DB had all been set

to the same value) but nobody had deleted the losing version of the page. So every

time I had to make a change to the top page, I faithfully replicated my changes across

both versions, wasting a lot of time in the process.

Licensed to UNKNOWN UNKNOWN <Eugenecheng10@gmail.com>

13Common legacy code traits and refactorings

A/B TESTING A/B testing is a commonly used process to investigate the effect

that a change to a website will have on users’ behavior. The basic idea is to

introduce the change to only a limited segment of the site’s users at first.

Users are separated into two buckets, A and B, and one group is served the

normal site, while the other is served a version of the site that includes the

change. You then measure key metrics (page views, attention time, scroll

depth, and so on) for each user segment and compare the results.

EXPIRED CODE

It’s common for business logic to apply only within a certain timespan, especially in

web applications. For example, you might run a particular ad campaign or A/B test

for a few weeks. In World of RuneQuest, perhaps you run half-price sales on in-game

purchases occasionally. This often requires corresponding date-specific logic in the

code, so it’s common to see code that looks like this:

if (new DateTime("2014-10-01").isBeforeNow() &&

new DateTime("2014-11-01").isAfterNow()) {

// do stuff ...

}

While there’s nothing wrong with temporary code like this, developers often forget to

go back and delete it after it has served its purpose, leading to a codebase littered with

expired code.

There are a couple of ways of avoiding this problem. One is to file a ticket in your

issue tracker to remind yourself to delete the code. In this case, make sure that the

ticket has a deadline and is assigned to a specific person; otherwise it’s easily ignored.

A smarter solution is to automate the check for expired code.

1 When writing code that has a limited lifespan, add a code comment in a specific

format to mark it as expiring code.

2 Write a script that can search through the codebase, parse these comments, and

flag any expired ones.

3 Set up your CI server to run this script regularly and fail the build if it finds any

expired code. This should be much harder to ignore than a ticket in the issue

tracker.

The following code shows an example of one of these comments.

// EXPIRES: 2014-11-01

if (new DateTime("2014-10-01").isBeforeNow() &&

new DateTime("2014-11-01").isAfterNow()) {

// do stuff ...

}

AUTOMATING EXPIRY CHECKS USING MACROS In languages that support mac-

ros (running code at compile time), it’s possible to make the project fail to

compile if there’s any expired code lying around. I know of a couple of Scala

libraries that can do this for you: Fixme (https://github.com/tysonjh/fixme)

and DoBy (https://github.com/leanovate/doby).

Licensed to UNKNOWN UNKNOWN <Eugenecheng10@gmail.com>

14 CHAPTER 4 Refactoring

4.2.2 Toxic tests

When you’re handed a legacy project to maintain, you might count yourself lucky if it

includes some automated tests. They can often act as a good substitute for documen

tation, and the presence of tests gives a hint that the code quality might be reasonable.

But be careful: there are some kinds of tests that are worse than no tests at all. I call

these toxic tests. Let’s have a look at some of them.

TESTS THAT DON’T TEST ANYTHING

The basic template for a good software test, no matter whether it’s manual or auto-

mated, unit, functional, system, or whatever, can be summed up in just three words:

given-when-then.

 Given some preliminary conditions and assumptions,

 when I do this

 then this should be the result.

Surprisingly often I encounter tests in legacy projects that don’t fit this simple pattern.

I see a lot of tests that are missing the “then” part, meaning that they don’t include any

assertions to check the result of the test against what was expected.

Imagine that World of RuneQuest uses an event bus to manage in-game events and

their corresponding notifications. For example, when a player proposes a treaty with

another player, an event is posted to the event bus. A listener might pick up this event

and send a notification mail to the player in question. The event bus is implemented

using a bounded queue data structure that automatically discards the oldest element

when it becomes full, in order to bound the amount of memory used. Here’s the

JUnit 3 test that the original developer wrote to check that the bounded queue

worked as expected.

public void testWorksAsItShould() {

int queueSize = 5;

BoundedQueue<Integer> queue =

new BoundedQueue<Integer>(queueSize);

for (int i = 1; i <= 20; i++) {

queue.enqueue(i);

}

while (!queue.isEmpty()) {

System.out.println(queue.dequeue());

}

Most likely the test was written before the days of CI, so the author never expected it to

be run more than once. They ran the test, manually verified that the numbers printed

to the screen matched what they expected, and then forgot about it.

But these days that kind of testing just doesn’t cut the mustard. We want our auto-

mated tests to guard against regressions, but the preceding test doesn’t. Even if you

accidentally change the behavior of the

BoundedQueue

class, the test won’t fail; it will

simply spit out a different set of numbers to the console.

Licensed to UNKNOWN UNKNOWN <Eugenecheng10@gmail.com>

15Common legacy code traits and refactorings

Tests like this one are particularly toxic because they look and feel like a test, even

though they aren’t testing anything at all. They falsely inflate the project’s test count

and test coverage, giving developers a false sense of security. The solution is simple:

either fix the test by adding proper assertions, or delete it. (In this particular case, an

even better solution would be to delete both the test and the

BoundedQueue

class itself,

replacing it with a trustworthy third-party implementation such as Guava’s

Evicting-

Queue

BRITTLE TESTS

Good unit tests can prove valuable when refactoring, by providing assurances that the

behavior of given parts of the codebase is preserved. But if you find that tests often

break when you refactor, it may be a sign that the tests are too brittle. In this case, the

tests become a hindrance, as you end up spending more time fixing them than refac-

toring.

A common cause of fragility is unit testing at too fine-grained a level. Continuing

our

BoundedQueue

example, imagine you wrote a test for it like the following (this

time using JUnit 4 syntax).

@Test

public void wibbleFlagIsSet() throws Exception {

int queueSize = 5;

BoundedQueue<Integer> queue =

new BoundedQueue<Integer>(queueSize);

Field wibble =

Expose the private

field “wibble”

BoundedQueue.class.getDeclaredField("wibble");

wibble.setAccessible(true);

assertThat(wibble.getBoolean(queue), is(false));

Flag should

start off

false

for (int i = 1; i <= queueSize; i++) {

Fill the queue

queue.push(i);

}

assertThat(wibble.getBoolean(queue), is(true));

Flag should

now be true

}

This test uses Java reflection hackery to expose a private field and check its value. So if

you ever remove or rename this field in the course of a refactoring, the test will break.

In general there’s no need to write tests like

this. We should be testing the behav-

ior that components expose to each other, not any inte

rnal state they might be hold-

ing. If you ever find a test that’s accessing private members

of a class, or you find

yourself wanting to write one, it might be a hint that the class contains too much state

or is doing too much. You should consider splitting it into smaller classes that are eas-

ier to test.

RANDOMLY FAILING TESTS

A good test is completely deterministic, meaning that its result shouldn’t be affected by

changes in

CPU load, thread scheduling, network congestion, other tests running in

parallel, or any other external factor. But some tests don’t achieve this gold standard

Licensed to UNKNOWN UNKNOWN <Eugenecheng10@gmail.com>

剩余154页未读，继续阅读

weixin_44006464

粉丝: 0
资源: 4

.NET Core微服务探索指南

The C Book.pdf

Exploring cross platform unit testing tools for .NET Core.pptx

C# 7 and .NET Core Cookbook

Exploring Causal Relationships with Streaming Features

.NET Core 3.0 深入探索：通过代码生成和元数据检查

Bioinformatics: Exploring Local Alignment with Blast and Tools

exploring_microservices:连接我为学习微服务而构建的其他库的主仓库

book-exploring-async-basics:“The Node Experiment - Exploring Async Basics with Rust”一书的存储库

everydaythings:将“Exploring Everyday Things with R and Ruby”一书中的编程示例重写为 Julia

exploring chemistry with electronic structure methods

最新资源