构建工程组织的生产级微服务标准体系

5星 · 超过95%的资源需积分: 10 143 浏览量更新于2024-07-20 1 收藏 8.38MB PDF 举报

《生产就绪微服务》（Production-Ready Microservices）由Susan J. Fowler撰写，这本书旨在帮助工程组织构建标准化的微服务系统，以确保在生产环境中达到高效、可靠和可维护的水平。作者Susan Fowler以其丰富的经验，从实践者的角度出发，深入探讨了如何将微服务架构应用于实际的工程项目，使之真正成为企业级的解决方案。该书的核心知识点包括： 1. **微服务概念介绍**：阐述微服务架构的优势，如模块化、独立部署、易于扩展和故障隔离等，以及它如何适应快速变化的需求和技术环境。 2. **设计原则**：书中详细介绍了生产就绪微服务的设计原则，包括单一职责原则、最小粒度服务、自我管理和服务发现等，这些都是构建稳健系统的基础。 3. **标准化流程**：强调在组织内部建立统一的服务开发、测试、部署和监控标准，确保每个微服务都能遵循一致的最佳实践。 4. **技术选型与实现**：涵盖了微服务架构的常见技术栈，如容器化（Docker）、API Gateway、消息队列、服务注册与发现（如Eureka或Consul）、以及数据库和缓存的设计策略。 5. **安全与治理**：讨论了微服务安全的重要性，包括API安全、服务间通信安全以及身份验证和授权机制。同时，书中也涉及了如何管理和治理分布式系统的复杂性。 6. **持续集成与交付（CI/CD）**：讲解如何通过自动化工具链实现微服务的快速迭代和部署，确保高可用性和稳定性。 7. **案例研究与实战经验**：书中提供了实际项目中的应用实例，分享了在大型工程组织中实施微服务架构的成功经验和教训。 8. **监控与故障排查**：讲述了如何通过日志、指标和事件驱动的监控体系来检测和处理微服务的问题，以及应对故障的策略。 9. **文化和团队协作**：探讨了在构建生产就绪微服务时，如何培养工程团队的微服务思维，以及如何促进跨团队协作和知识共享。 10. **未来趋势与挑战**：分析了微服务架构可能面临的未来发展趋势，以及如何应对随着技术演进带来的新挑战。《生产就绪微服务》是一本实用的指南，为读者提供了从概念理解到实战操作的全面支持，旨在帮助工程师们在实际工作中打造出高效、可扩展且稳定的微服务架构。

Members have access to thousands of books, training videos, Learning Paths, interac‐

tive tutorials, and curated playlists from over 250 publishers, including O’Reilly

Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Profes‐

sional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press,

John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe

Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and

Course Technology, among others.

For more information, please visit http://oreilly.com/safari.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938 (in the United States or Canada)

707-829-0515 (international or local)

707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional

information. You can access this page at http://bit.ly/prod-ready_microservices.

To comment or ask technical questions about this book, send email to bookques‐

tions@oreilly.com.

For more information about our books, courses, conferences, and news, see our web‐

site at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments

This book is dedicated to my better half, Chad Rigetti, who took time away from

building quantum computers to listen to all of my rants about microservices, and

who joyfully encouraged me every step of the way. I could not have written this book

without all of his love and wholehearted support.

It is also dedicated to my sisters, Martha and Sara, whose grit, resilience, courage, and

joy inspire me in every moment and aspect of my life, and also to Shalon Van Tine,

who has been my closest friend and fiercest supporter for so many years.

xiv | Preface

CHAPTER 1

Microservices

In the past few years, the technology industry has witnessed a rapid change in

applied, practical distributed systems architecture that has led industry giants (such

as Netflix, Twitter, Amazon, eBay, and Uber) away from building monolithic applica‐

tions to adopting microservice architecture. While the fundamental concepts behind

microservices are not new, the contemporary application of microservice architecture

truly is, and its adoption has been driven in part by scalability challenges, lack of effi‐

ciency, slow developer velocity, and the difficulties with adopting new technologies

that arise when complex software systems are contained within and deployed as one

large monolithic application.

Adopting microservice architecture, whether from the ground up or by splitting an

existing monolithic application into independently developed and deployed micro‐

services, solves these problems. With microservice architecture, an application can

easily be scaled both horizontally and vertically, developer productivity and velocity

increase dramatically, and old technologies can easily be swapped out for the newest

ones.

As we will see in this chapter, the adoption of microservice architecture can be seen

as a natural step in the scaling of an application. The splitting of a monolithic applica‐

tion into microservices is driven by scalability and efficiency concerns, but microser‐

vices introduce challenges of their own. A successful, scalable microservice ecosystem

requires that a stable and sophisticated infrastructure be in place. In addition, the

organizational structure of a company adopting microservices must be radically

changed to support microservice architecture, and the team structures that spring

from this can lead to siloing and sprawl. The largest challenges that microservice

architecture brings, however, are the need for standardization of the architecture of

the services themselves, along with requirements for each microservice in order to

ensure trust and availability.

From Monoliths to Microservices

Almost every software application written today can be broken into three distinct ele‐

ments: a frontend (or client-side) piece, a backend piece, and some type of datastore

(Figure 1-1). Requests are made to the application through the client-side piece, the

backend code does all the heavy lifting, and any relevant data that needs to be stored

or accessed (whether temporarily in memory of permanently in a database) is sent to

or retrieved from wherever the data is stored. We’ll call this the three-tier architecture.

Figure 1-1. ree-tier architecture

There are three different ways these elements can be combined to make an applica‐

tion. Most applications put the first two pieces into one codebase (or repository),

where all client-side and backend code are stored and run as one executable file, with

a separate database. Others separate out all frontend, client-side code from the back‐

end code and store them as separate logical executables, accompanied by an external

database. Applications that don’t require an external database and store all data in

memory tend to combine all three elements into one repository. Regardless of the

way these elements are divided or combined, the application itself is considered to be

the sum of these three distinct elements.

Applications are usually architected, built, and run this way from the beginning of

their lifecycles, and the architecture of the application is typically independent of the

product offered by the company or the purpose of the application itself. These three

architectural elements that comprise the three-tier architecture are present in every

website, every phone application, every backend and frontend and strange enormous

enterprise application, and are found as one of the permutations described.

In the early stages, when a company is young, its application(s) simple, and the num‐

ber of developers contributing to the codebase is small, developers typically share the

burden of contributing to and maintaining the codebase. As the company grows,

more developers are hired, new features are added to the application, and three sig‐

nificant things happen.

First comes an increase in the operational workload. Operational work is, generally

speaking, the work associated with running and maintaining the application. This

usually leads to the hiring of operational engineers (system administrators, TechOps

engineers, and so-called “DevOps” engineers) who take over the majority of the

operational tasks, like those related to hardware, monitoring, and on call.

2 | Chapter 1: Microservices

剩余171页未读，继续阅读

libingchen

粉丝: 29
资源: 263

构建工程组织的生产级微服务标准体系

Production-Ready Microservices Building Standardized Systems Across an 无水印原版pdf

Production-Ready Microservices Building Standardized Systems Across

Production-Ready Microservices(O'Reilly,2016)

spring-boot-starter-actuator

毕设关于springboot的外文翻译

spring boot

一篇springboot的英文文献

npm install --global windows-build-tools npm install --global node-gyp npm install --global --production windows-build-tools npm install --global --production windows-build-tools --vs2015把这几个加上镜像

// Fields of the User. func (User) Fields() []ent.Field { return []ent.Field{ field.Int64("id"). DefaultFunc(func() int64 { // An example of a dumb ID generator - use a production-ready alternative instead. return time.Now().Unix() << 8 | atomic.AddInt64(&counter, 1) % 256 }), } }

spring-boot

最新资源