云原生Go：构建可扩展的云服务指南

Native

Cloud

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

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Cloud.Native.Go 是一本全面介绍构建云服务的指南，旨在帮助开发者构建能够满足当今用户需求的大型云应用，并能动态扩展以处理几乎任何级别的数据、流量和用户。作者 Kevin Hoffman 和 Dan Nemeth 深入探讨了现代云原生应用，并介绍了Go语言，这是一种适用于云开发的高性能语言。书中涵盖从使用Go构建微服务，到使用ReactJS和Flux添加前端组件，再到建立持续交付管道和监控生产环境应用性能的各种技术。" 在《Cloud Native Go》中，读者将学习到： 1. **云的心态与纪律**（The Way of the Cloud）：开发优秀的云软件本质上是关于思维方式和纪律的。书中引导读者理解云开发的核心理念，培养适应云环境的开发习惯。 2. **Go语言介绍**（Go Primer）：Go语言被推崇为构建云原生微服务的理想选择，因为其简洁优雅且性能强大。书中会详细介绍Go语言的关键特性和如何利用它进行高效开发。 3. **持续交付与部署**（Delivering Continuously）：通过Wercker、Docker和Dockerhub等工具，学习如何构建持续交付管道，实现自动化应用推送至主流云平台。 4. **微服务设计与构建**（Building Microservices in Go）：介绍如何设计和以测试优先的方式构建微服务架构，以支持高可扩展性和可维护性。 5. **使用后台服务**（Using Backing Services）：探讨如何有效利用各种后台服务，如数据库、缓存等，来增强应用功能。 6. **事件溯源与CQRS**（Event Sourcing and CQRS）：介绍如何利用这些模式处理大规模数据和高吞吐量，以应对云环境中可能出现的挑战。 7. **云中的安全实践**（Security in the Cloud）：详细讲解云安全的最佳实践，包括应该做什么、不应该做什么，以及各种安全选项。 8. **云中的Web应用程序**（Building a Web Application with Go）：学习使用Go构建Web应用程序，同时考虑云环境下的动态扩展和故障恢复。 9. **WebSocket工作原理**（Working with WebSockets）：了解如何在云环境中使用WebSocket实现实时通信。 10. **React与Flux构建响应式UI**（Building Web Views with React and Creating UIs that Scale with Flux）：学习如何利用React和Flux创建大规模、云友好的图形用户界面，以提供流畅的用户体验。 11. **完整应用实例**（Creating a Full Application—World of FluxCraft）：通过一个名为World of FluxCraft的案例，综合应用前面章节所学知识，构建一个完整的云应用。通过《Cloud Native Go》，开发者将掌握构建云原生应用的全方位技能，从基础概念到高级技术，从语言选择到架构设计，再到安全性和监控，从而能够构建出能够适应未来需求的弹性、高性能云服务。

资源详情

资源推荐

ptg18655054

Chapter 1The Way of the Cloud

and supporting sites, exudes the passion we have for the way. Hopefully, by the time you have

finished this book, you will be as passionate about the way as we are.

We will be discussing:

■

The virtues of the way of the cloud

■

Justifications for choosing the Go language for cloud native microservices development

The Virtues of the Way of the Cloud

Contrary to popular belief, there are days when what we do isn’t all rainbows and unicorns.

Atsome point, something happens and our passion becomes a chore. We trudge to work and

we go through the motions of adding code, praying it works, and deploying. We lose sight of

the fact that what we build is art, and we fail to give our craft the love and devotion it deserves.

In one degree or another, this has probably happened to us all at some point in our careers.

Hopefully an inspiring boss, a new technology or language, or a new job turned things around

and rescued us from this pit.

For us, this rescue came in the form of the way of the cloud. It changed our perspective on

software development and how we see the world. We can see the art in what we build now, and

software has become fun again, and there is no way we can go back to building applications

any other way.

Throughout our years of building software for enterprises, startups, hobbies, and everything in

between, we have developed a set of virtues that we feel give us the best chance at creating

scalable, reliable, and predictable software that embraces the cloud and everything it has to offer.

While there’s nothing that says these virtues can only apply to cloud software, this book is

about cloud native software development and so throughout the book, every code sample we

produce and every topic we discuss will exude the virtues below. In fact, we followed these

virtues in producing this book—everything from the prose to the code to the companion site.

Favor Simplicity

The Way of the Cloud

Favor simplicity in everything that you do.

Question everything that appears to defy simplicity. What you’re building is already complex

enough; there is absolutely no need to inject further complexity or ceremony into your work.

Question every tool. Ask yourself if the tool is making your life easier, or compensating or

apologizing for complexity elsewhere in the system. If the answer is the latter, ditch the tool, and

the reason for using it.

ptg18655054

The Virtues of the Way of the Cloud

Question all of your code. If it’s too complex to read, change the language or framework

that’scausing that complexity. If there is so much magic happening behind the scenes

inthecode you can’t see that it’s difficult to figure out what happens when or where,

changethecode.

Here is the litmus test for simplicity:

■

Is your IDE optional?

■

Can you build and deploy from the command line?

■

Can a new team member quickly figure out what’s going on just by reading the code?

Tools and IDEs must make our lives better by automating routine tasks, and simplifying manual

tasks by reducing frustration or time. Tools must never be mandatory. If you have to use a

specific IDE because your code will not generate or compile without it, then you are absolutely

not following the way of the cloud, and not favoring simplicity.

Anything that you can do from the command line can be automated by a script or a continu-

ous delivery tool. Therefore, if you can build, test, and deploy your application from a

command line, then you can automate all of those tasks.

This may seem like a harsh stance, and you have every right to disagree with us. However, at

least until you finish reading this book, try and apply this virtue to all of your development

efforts. You will not be disappointed.

The only people who claim that you cannot have cloud native and simplicity at the same time

are those apologizing for complexity they either created or aren’t willing to give up.

Test First, Test Everything

The Way of the Cloud

Employ Test-Driven Development. Test everything, everywhere.

Testing is your first and best defense against the evils of hope-based computing.

Pretty much everyone can agree that testing is a good idea, but few teams ever agree on how

much testing should be necessary. Before we answer that, consider this: why do we test our

software?

Of course we want bug-free software, and we want our customers to be happy, and we’d like

to make hojillions of dollars while we’re at it. But, the core of testing is none of those things.

Atthe most basic level, testing gives us confidence.

Have you ever been in a room when someone is about to exercise some feature of your

application in front of some very important or influential people? Do you remember the feeling

of panic wash over you right before the crucial test?

ptg18655054

The Virtues of the Way of the Cloud

You may often run into situations on teams where leadership doesn’t feel that the time spent

on extensive testing is worth it. It’s pretty easy to manipulate a spreadsheet to back up the

assertion that adequate testing costs too much money. Therefore, to counter that thinking,

consider the following analogy:

When you build your applications locally, you’ve got all the tools you could imagine at your

disposal. You can connect to a debugger, you can set and hit breakpoints. In some cases you

can even pause an app, manipulate data in memory, and then resume it. This gives you a false

sense of confidence, and can even make you think integration and unit testing is unnecessary,

given how much time you’ve spent in the debugger.

Consider then a situation where what you’re building isn’t just a piece of software being

deployed on a computer sitting a few feet from you. Imagine that what you’re building

is actually a spacecraft, being launched into deep space. Once launched, you can’t touch

it, you can’t grab a screwdriver and make last-minute adjustments, and if something fails

catastrophically a few million miles from home, that’s the end of the line.

When you deploy to the cloud, you are relinquishing a lot of hands-on control. It might not

be as complicated as launching a satellite, but you give up instantiation control, you can’t set

breakpoints, and you generally don’t have runtime introspection.

The next time someone waves a spreadsheet at you claiming that testing costs too much

money, simply reply and ask them the cost of complete and total failure of the product at every

level, because that is the real cost of skimping on tests.

This brings us back to confidence. If you have confidence in the fact that your application will

function as it should, you can use that confidence as a bedrock for other huge benefits, like

continuous delivery (discussed next).

The bottom line is you should adopt Test-Driven Development

, and you must build

confidence in the services you produce by testing everything inside and out of every service

you build.

Release Early, Release Often

The Way of the Cloud

Every checkin is a potential production release, deployed via CD pipeline.

In the previous section, we talked about the fear of people using your application because you

lack the confidence that it will behave as it should. There is another kind of fear that we need

to confront head-on: the fear of releasing.

2 For more information on Test-Driven Development, check out: Beck, Kent. (2003) Test-Driven

Development: By Example. Addison-Wesley Professional.

ptg18655054

Chapter 1The Way of the Cloud

There are organizations where it is the norm for a release to be a stop-the-world event.

It is planned months in advance, emergency personnel are on standby, ambulances and

firefightersare in position, and nearly every person who ever checked in a line of code, or

oversaw the checkins, is on the phone at midnight in order to carry out this release. The

Guinness Book of World Records is on the phone so they can be there to record the event just

in case, for the first time in history, nothing goes wrong.

Companies that operate this way try to mitigate the problem by throwing more resources,

more people, and more infrastructure and controls at a release. Sometimes they will even delay

releases, and release less often. This is the exact opposite of what you should do.

The only way to get over the fear of releasing is to release more frequently.

The cascade of benefits starts when every developer on your team firmly believes that every

single commit to the source control system could end up in production within a matter of

days. This leads to a level of rigor and discipline that most people don’t normally apply to their

code. Additionally, if you know your code is going to be released rapidly, you are far more likely

to test your code, because the last thing you want is a production release with low confidence,

right?

Automate Everything

The Way of the Cloud

Everything that can be automated, should be automated.

Now that we have confidence that our code is being tested, being written in a way that

facilitates testing, and that we’re releasing so regularly that we no longer fear the looming

specter of release, we can start making our lives better and increasing productivity.

Anything you do more than once per day is a candidate for automation.

The first and probably most important thing to automate is your release process itself. Within

minutes of a checkin, some automated system should be running tests on your code, validating

that the code meets your standards, and deploying an immutable build artifact to some envi-

ronment where it can be used for manual and integration testing.

Things that you do manually are error-prone. As the easily distracted humans that we are,

wecan forget steps, we can do steps in the wrong order, and we can do extra steps we don’t

need. Once we’ve certified an automated process, it gives us even more confidence.

We should be able to reach a point where, after a push to source control, if no sirens go off, no

Darth Vader heads light up, and no angry e-mails get sent out, then we have confidence that

our changes did not cause unit or integration tests to fail. There’s still more testing that needs

to be done prior to production, but we have enough confidence that our checkin is a release

candidate ready to go through the pre-production certification process.

剩余258页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

云原生Go：构建可扩展的云服务指南

Cloud Native Java

cloud-native-programming-golang

Cloud Native Python epub

spring.cloud.nacos.discovery全部配置及示例

nacos的spring.cloud.nacos.server-addr和spring.cloud.nacos.discovery:server-addr配置有什么区别？

nacos的spring.cloud.nacos.server-add和spring.cloud.nacos.discovery.server-addr区别

spring.cloud.config.server.composite错误是什么原因

接口cloud.openapi.login.code2Session的使用方法

<spring-cloud.version>Greenwich.RELEASE</spring-cloud.version>

微信小程序开发中env: cloud.DYNAMIC_CURRENT_ENV的意思，以及怎么查找cloud.DYNAMIC_CURRENT_ENV

wx.cloud.cdn 和wx.cloud.uploadFile什么区别

spring.cloud.nacos.discovery.networkInterface

IllegalArgumentException: Not a managed type: class com.pig4cloud.pig.resources.signUp.entity.OrgEnrollment

wx.cloud.callfunctionz怎么用

java代码获取spring.cloud.nacos.server-addr

spring.cloud.gateway.routes.predicates.name

cloud.uploadFile如何用

wx.cloud.uploadFile

wx.cloud.database().command

最新资源