云原生Java：构建弹性系统

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

"Cloud Native Java 是一本由 Josh Long 和 Kenny Bastani 合著的书籍，主要探讨如何利用 Spring Boot、Spring Cloud 和 Cloud Foundry 设计出具有弹性的云原生系统。书中涵盖了云原生应用开发的核心概念和技术，旨在帮助读者理解和实践云原生Java应用程序的构建与部署。" 本书深入解析了以下几个关键知识点： 1. **云原生（Cloud Native）**：云原生是一种构建和运行应用程序的方法，强调可移植性、松耦合、微服务架构、快速迭代和持续交付。通过采用云原生原则，开发者能够充分利用云计算的弹性、可扩展性和高可用性。 2. **Spring Boot**：Spring Boot 是一个简化 Spring 应用程序初始搭建以及开发过程的框架。它提供了一种快速构建独立运行的、生产级的基于 Spring 应用的方式，内置了如嵌入式Web服务器、自动配置支持、starter依赖等特性。 3. **Spring Cloud**：Spring Cloud 是一组工具包，用于快速实现分布式系统的常见模式，如配置管理、服务发现、断路器、智能路由、微代理、控制总线等。Spring Cloud 基于 Spring Boot，使得开发者可以轻松地在 Spring 应用中实现云原生功能。 4. **Cloud Foundry**：Cloud Foundry 是一个开源的平台即服务（PaaS），用于构建、部署和管理微服务应用。它提供了自动化部署、动态扩展、自我修复等功能，使得开发者可以专注于编写代码，而无需关注底层基础设施。 5. **设计弹性系统**：书中详细阐述了如何通过设计模式和最佳实践来构建能够抵御故障、具备自恢复能力的系统。这包括使用服务发现、负载均衡、健康检查、容错机制（如断路器模式）等技术。 6. **容器化和Docker**：讨论了如何将Java应用容器化，利用 Docker 提供轻量级的运行环境，提高应用的可移植性和部署效率。同时也可能涉及Kubernetes等容器编排工具。 7. **持续集成与持续交付(CI/CD)**：介绍如何结合Jenkins、GitLab CI/CD等工具实现快速的软件开发流程，确保代码质量并加速产品发布。 8. **监控与日志管理**：探讨如何利用Prometheus、ELK Stack（Elasticsearch、Logstash、Kibana）等工具进行应用性能监控和日志分析，以便及时发现并解决问题。 9. **安全性**：讲解如何在云原生环境中实现安全的认证、授权和数据加密，如OAuth2、JWT（JSON Web Tokens）、SSL/TLS等。 10. **最佳实践**：书中会分享作者的经验和见解，指导读者如何在实际项目中应用这些技术，避免常见的陷阱和误区。通过学习《Cloud Native Java》，读者不仅可以掌握云原生Java应用的开发技术，还能了解到如何构建和运行面向云的、高可用的现代应用程序，从而在数字化转型的大潮中保持竞争力。

Chapter 1. The Cloud Native Application

The patterns for how we develop software, both in teams and as individuals, are always

evolving. The open source software movement has provided the software industry with

somewhat of a Cambrian explosion of tools, frameworks, platforms, and operating systems

— all with an increasing focus on flexibility and automation. A majority of today’s most

popular open source tools focus on features that give software teams the ability to

continuously deliver software faster than ever before possible, at every level, from

development to operations.

Amazon’s Story

In the span of two decades, starting in the early ’90s, an online bookstore headquartered in

Seattle called Amazon.com grew into the world’s largest online retailer. Known today simply

as Amazon, the company now sells far more than just books. In 2015, Amazon surpassed

Walmart as the most valuable retailer in the United States. The most interesting part of

Amazon’s story of unparalleled growth can be summarized in one simple question: how did a

website that started out as a simple online bookstore transform into one of the largest retailers

in the world — without ever opening a single retail location?

It’s not hard to see how the world of commerce has been shifted and reshaped around digital

connectivity, catalyzed by ever-increasing access to the internet from every corner of the

globe. As personal computers became smaller, morphing into the ubiquitous smartphones,

tablets, and watches we use today, we’ve experienced an exponential increase in accessibility

to distribution channels that are transforming the way the world does commerce.

Amazon’s CTO, Werner Vogels, oversaw the technical evolution of Amazon from a hugely

successful online bookstore into one of the world’s most valuable technology companies and

product retailers. In June 2006, Vogels was interviewed in a piece for the computer magazine

ACM Queue on the rapid evolution of the technology choices that powered Amazon’s

growth. In the interview, Vogels talks about the core driver behind it.

A large part of Amazon.com’s technology evolution has been driven to enable this continuing

growth, to be ultra-scalable while maintaining availability and performance.

Werner Vogels, “A Conversation with Werner Vogels,” ACM Queue 4, no. 4 (2006): 14–22.

Vogels goes on to state that for Amazon to achieve ultrascalability, it needed to move toward

a different pattern of software architecture. He mentions that Amazon.com started as a

monolithic application. Over time, as more and more teams operated on the same application,

the boundaries of ownership of the codebase began to blur. “There was no isolation and, as a

result, no clear ownership,” said Vogels.

Vogels pinpoints that shared resources such as databases made it difficult to scale out the

overall business. The greater the number of shared resources, whether application servers or

databases, the less control teams had when delivering features into production.

You build it, you run it.

Werner Vogels, CTO, Amazon

Vogels touches on a common theme that cloud native applications share: the idea that teams

own what they are building. He goes on to say that “the traditional model is that you take

your software to the wall that separates development and operations, and throw it over and

then forget about it. Not at Amazon. You build it, you run it.”

In what has been one of the most reused quotes by prominent keynote speakers at some of the

world’s premier software conferences, the words “you build it, you run it” would later

become a slogan of a popular movement we know today simply as DevOps.

Many of the practices that Vogels spoke about in 2006 were seeds for popular software

movements that are thriving today. Practices such as DevOps and microservices can be tied

back to the ideas that Vogels introduced over a decade ago. While ideas like these were being

developed at large internet companies similar to Amazon, the tooling around these ideas

would take years to develop and mature into a service offering.

In 2006 Amazon launched a new product named Amazon Web Services (AWS). The idea

behind AWS was to provide a platform, the same platform Amazon used internally, and

release it as a service to the public. Amazon was keen to see the opportunity to commoditize

the ideas and tooling behind that platform. Many of the ideas that Vogels introduced were

already built into the Amazon.com platform; by releasing the platform as a service to the

public, Amazon would enter a new market called the public cloud.

The ideas behind the public cloud were sound. Virtual resources could be provisioned on-

demand without needing to worry about the underlying infrastructure. Developers could

simply rent a virtual machine to house their applications without needing to purchase or

manage the infrastructure. This approach was a low-risk self-service option that would help

to grow the appeal of the public cloud, with AWS leading the way in adoption.

It would take years before AWS would mature into a set of services and patterns for building

and running applications that are designed to be operated on a public cloud. While many

developers flocked to these services for building new applications, many companies with

existing applications still had concerns with migrations. Existing applications were not

designed for portability. Also, many applications were still dependent on legacy workloads

that were not compatible with the public cloud.

In order for most large companies to take advantage of the public cloud, they would need to

make changes in the way they developed their applications.

The Promise of a Platform

Platform is an overused word today.

When we talk about platforms in computing, we are generally talking about a set of

capabilities that help us to either build or run applications. Platforms are best summarized by

the nature in which they impose constraints on how developers build applications.

Platforms are able to automate tasks that are not essential to supporting the business

requirements of an application. This makes development teams more agile in the way they

are able to support only the features that help differentiate value for the business.

Any team that has written shell scripts or stamped containers or virtual machines to automate

deployment has built a platform, of sorts. The question is: what promises can that platform

keep? How much work would it take to support the majority (or even all) of the requirements

for continuously delivering new software?

When we build platforms, we are creating a tool that automates a set of repeatable practices.

Practices are formulated from a set of constraints that translate valuable ideas into a plan.

Ideas: What are our core ideas of the platform and why are they valuable?

Constraints: What are the constraints necessary to transform our ideas into practices?

Practices: How do we automate constraints into a set of repeatable practices?

At the core of every platform are simple ideas that, when realized, increase differentiated

business value through the use of an automated tool.

Let’s take for example the Amazon.com platform. Werner Vogels stated that by increasing

isolation between software components, teams would have more control over features they

delivered into production.

Ideas:

By increasing isolation between software components, we are able to deliver parts of the

system both rapidly and independently.

By using this idea as the platform’s foundation, we are able to fashion it into a set of

constraints. Constraints take the form of an opinion about how a core ideal will create value

when automated into a practice. The following statements are opinionated constraints about

how isolation of components can be increased.

Constraints:

Software components are to be built as independently deployable services.

All business logic in a service is encapsulated with the data it operates on.

There is no direct access to a database from outside of a service.

Services are to publish a web interface that allows access to its business logic from

other services.

With these constraints, we have taken an opinionated view on how isolation of software

components will be increased in practice. The promises of these constraints, when automated

into practices, will provide teams with more control over how features are delivered to

production. The next step is to describe how these constraints can be captured into a set of

repeatable practices.

Practices that are derived from these constraints should be stated as a collection of promises.

By stating practices as promises, we maintain an expectation with the platform’s users of how

they will build and operate their applications.

Practices:

A self-service interface is provided to teams that allows for the provisioning of

infrastructure required to operate applications.

Applications are packaged as a bundled artifact and deployed to an environment using

the self-service interface.

Databases are provided to applications in the form of a service, and are to be

provisioned using the self-service interface.

An application is provided with credentials to a database as environment variables, but

only after declaring an explicit relationship to the database as a service binding.

Each application is provided with a service registry that is used as a manifest of where

to locate external service dependencies.

Each of the practices listed above takes on the form of a promise to the user. In this way, the

intent of the ideas at the core of the platform are realized as constraints imposed on

applications.

Cloud native applications are built on a set of constraints that reduce the time spent

doing undifferentiated heavy lifting.

When AWS was first released to the public, Amazon did not force its users to adhere to the

same constraints that they used internally for Amazon.com. Staying true to the name Amazon

Web Services, AWS is not itself a cloud platform, but rather a collection of independent

infrastructure services that can be composed into automated tooling resembling a platform of

promises. Years after the first release of AWS, Amazon began offering a collection of

managed platform services, with use cases ranging from IoT (Internet of Things) to machine

learning.

If every company needs to build its own platform from scratch, the amount of time delivering

value in applications is delayed until the platform is fully assembled. Companies that were

early adopters of AWS would have needed to assemble together some form of automation

resembling a platform. Each company would have had to bake in a set of promises that

captured the core ideas of how to develop and deliver software into production.

More recently, the software industry has converged on the idea that there is a basic set of

common promises that every cloud platform should make. These promises will be explored

throughout this book using the open source Platform as a Service (PaaS) Cloud Foundry. The

core motivation behind Cloud Foundry is to provide a platform that encapsulates a set of

common promises for quickly building and operating. Cloud Foundry makes these promises

while still providing portability between multiple different cloud infrastructure providers.

The subject of much of this book is how to build cloud native Java applications. We’ll focus

largely on tools and frameworks that help reduce undifferentiated heavy lifting, by taking

advantage of the benefits and promises of a cloud native platform.

The Patterns

New patterns for how we develop software enable us to think more about the behavior of our

applications in production. Both developers and operators, together, are placing more

emphasis on understanding how their applications will behave in production, with fewer

assurances of how complexity will unravel in the event of a failure.

As was the case with Amazon.com, software architectures are beginning to move away from

large monolithic applications. Architectures are now focused on achieving ultra-scalability

without sacrificing performance and availability. By breaking apart components of a

monolith, engineering organizations are taking efforts to decentralize change management,

providing teams with more control over how features make their way to production. By

increasing isolation between components, software teams are starting to enter the world of

distributed systems development, with a focus on building smaller, more singularly focused

services with independent release cycles.

Cloud native applications take advantage of a set of patterns that make teams more agile in

the way they deliver features to production. As applications become more distributed (a result

of increasing isolation necessary to provide more control to the teams that own applications),

the chance of failure in the way application components communicate becomes an important

concern. As software applications turn into complex distributed systems, operational failures

become an inevitable result.

Cloud native application architectures provide the benefit of ultra-scalability while still

maintaining guarantees about overall availability and performance of applications. While

companies like Amazon reaped the benefits of ultra-scalability in the cloud, widely available

tooling for building cloud-native applications had yet to surface. The tooling and platform

would eventually surface as a collection of open source projects maintained by an early

pioneer of the public cloud: Netflix.

Scalability

To develop software faster, we are required to think about scale at all levels. Scale, in a most

general sense, is a function of cost that produces value. The level of unpredictability that

reduces that value is called risk. We are forced to frame scale in this context because building

software is fraught with risks. The risks created by software developers are not always known

to operators. By demanding that developers deliver features to production at a faster pace, we

are adding to the risks of its operation without having a sense of empathy for its operators.

The result of this is that operators grow distrustful of the software that developers produce.

The lack of trust between developers and operators creates a blame culture: people point

fingers instead of looking at systemic problems that lead to, or at least precipitate, problems

that negatively impact the business.

To alleviate the strain that is put on traditional structures of an IT organization, we need to

rethink how software delivery and operations teams communicate. Communication between

operations and developers can affect our ability to scale, as the goals of each party tend to

become misaligned over time. To succeed at this requires a shift toward a more reliable kind

of software development — one that puts emphasis on the experience of an operations team

inside the software development process; one that fosters shared learning and improvement.

Reliability

The expectations that are created between teams (development, operations, user experience,

etc.) are contracts. The contracts that are created between teams imply that some level of

service is provided or consumed. By looking at how teams provide services to one another in

the process of developing software, we can better understand how failures in communication

剩余588页未读，继续阅读

qq_36821241

粉丝: 0
资源: 9

云原生Java：构建弹性系统

Cloud Native Java

《Cloud native Java》英文原版（ 预览版 ）

OReilly.Cloud.Native.Java

Cloud-Native Applications in Java.pdf

百度商业运营技术团队的Cloud-Native实践.pdf

2017.08 page877 Cloud Native Java_ Designing Re - Josh Long.pdf )

cloud-native-java

Java远程方法调用.pdf

Cloud Native Patterns

JAVA核心知识点整理.pdf

最新资源

《Cloud native Java》英文原版（预览版）