《发布它》：打造生产级Web应用的深度指南

5星 · 超过95%的资源需积分: 10 141 浏览量更新于2024-07-26 7 收藏 5.11MB PDF 举报

"Release It! Design and Deploy Production-Ready Software" 《Release It!》是一本针对Web开发架构师的进阶性图书，旨在帮助读者全面理解Web开发中的问题和挑战。这本书由Michael Nygard撰写，是The Pragmatic Bookshelf出版的一部关于软件工程和架构设计的重要著作。书中的内容受到了业界专家如Tom Poppendieck和Jared Richardson的高度评价，他们认为这本书对实际项目中的问题提供了深刻的见解和实用的解决方案。在敏捷开发的背景下，每个迭代都强调交付可生产的代码。《Release It!》深入探讨了这对当今关键系统意味着什么。作者通过丰富的经验和洞察力，揭示了在实际操作中可能遇到的各种问题，并提供了应对这些问题的模式和策略。例如，书中可能会讨论如何确保系统的高可用性、容错性和可扩展性，这些都是在生产环境中至关重要的因素。书中的内容可能会涵盖以下几个关键知识点： 1. **系统稳定性**：如何设计和实现能够抵御故障、具有自我修复能力的系统，以确保服务的连续性。 2. **性能优化**：如何在系统设计阶段就考虑性能需求，避免在后期因性能问题而进行昂贵的重构。 3. **监控与日志管理**：如何有效地监控系统状态，及时发现并解决问题，以及如何管理和分析日志数据。 4. **容量规划**：如何预测和准备应对流量增长，以防止过载或崩溃。 5. **错误处理与回滚策略**：如何设计健壮的错误处理机制，以及在出现问题时如何优雅地回滚到稳定状态。 6. **部署策略**：如何实现无中断的部署，减少维护窗口期间的影响，以及自动化部署的重要性。 7. **安全性**：在系统设计和实施过程中，如何考虑安全问题，包括数据保护、访问控制和防止攻击。 8. **资源管理和成本控制**：如何合理分配和管理硬件、软件资源，同时控制运营成本。《Release It!》不仅提供理论知识，还包含大量实战案例和实用建议，是每个希望提升自己在软件工程和架构设计领域专业技能的开发者不可或缺的参考书。通过阅读本书，读者可以避免许多未知的错误，为公司的项目节省大量的时间和金钱，提高产品的质量和用户满意度。因此，这本书对于想要成为优秀Web开发架构师的人来说，无疑是一份宝贵的财富。

QUALITY OF LIFE 16

(See the sidebar on page 150.) It’s a terrible ir ony that these very early

decisions are also the least informed. This is when your team is most

ignorant of the eventual structure of the software in the beginning, yet

that is when some of the most irrevocable decisions must be made.

Even on “agile” projects,

decisions are best made with foresight. It

seems as if the designer must “use the force” to see the future in order

to select the most robust design. Since different alternatives often have

similar implementation costs but radically different lifecycle costs, it is

important to consider the effects of each decision on availability, capac-

ity, and ﬂexibility. I’ll show you the downstream effects of dozens of

design alternatives, with concrete examples of beneﬁcial and harmful

approaches. These examples all come from real systems I’ve worked on.

Most of them cost me sleep at one time or another.

1.3 Quality of Life

Release 1.0 is the beginning of your software’s life, not the end of the

project. Your quality of life after Release 1.0 depends on choices you

make long before that vital milestone.

Whether you wear the support pager, sell your labor by the hour, or pay

the invoices for the work, you need to know that you ar e dealing with a

rugged, Baja-tested, indestructible vehicle that will carry your business

forward, not a fragile shell of ﬁberglass that spends more time in the

shop than on the road.

1.4 The Scope of the Challenge

The “software crisis” is now more than thirty years old. According to These terms come from

the agile community. The

gold owner is the one

paying for the software.

The goal donor is the one

whose needs you are

trying to ﬁll. These are

seldom the same person.

the gold owners,softwarestillcoststoomuch.(But,seeWhy Does Soft-

ware Cost So Much? [DeM95]aboutthat.)Accordingtothegoal donors,

software still takes too long—even though schedules are measured in

months rather than years. Apparently, the supposed productivity gains

from the past thirty years have been illusory.

1. I’ll reveal myself here and now as a strong proponent of agile methods. Their emphasis

on early delivery and incremental improvements means software gets into production

quickly. Since production is the only place to learn how the software will respond to

real-world stimuli, I advocate any approach that begins the learning process as soon as

possible.

AMILLIO N DOLLARS HERE, A MILLION DOLLARS THERE 17

On the other hand, maybe some real productivity gains have gone into

attacking larger problems, rather than producing the same software

faster and cheaper. Over the past ten years, the scope of our systems

expanded by orders of magnitude.

In the easy, laid-back days of client/server systems, a system’s user

base would be measured in the tens or hundreds, with few dozen con-

current users at most. Now, sponsors glibly toss numbers at us such

as “25,000 concurrent users” and “4 million unique visitors a day.”

Uptime demands have increased, too. Whereas the famous “ﬁve nines”

(99.999%) uptime was once the province of the mainframe and its care-

takers, even garden-variety commerce sites are now expected to be

available 24 by 7 by 365.

Clearly, we’ve made tremendous strides even

to consider the scale of software we build today, but with the increased

reach and scale of our systems come new ways to break, more hostile

environments, and less tolerance for defects.

The increasing scope of this challenge—to build software fast that’s

cheap to build, good for users, and cheap to operate—demands con-

tinually improving architecture and design techniques. Designs appro-

priate for small brochureware websites fail outrageously when applied

to thousand-user, transactional, distributed systems, and we’ll look at

some of those outrageous failures.

1.5 A Million Dollars Here, a Million Dollars There

Alotisonthelinehere:yourproject’ssuccess,yourstockoptionsor

proﬁt sharing, your company’s survival, and even your job. Systems

built for QA often require so much ongoing expense, in the form of

operations cost, downtime, and software maintenance, that they never

reach proﬁtability, let alone net positive cash for the business, which

is reached only after the proﬁts generated by the system pay back the

costs incurred in building it. These systems exhibit low levels of avail-

ability, resulting in direct losses in missed revenue and sometimes even

larger indirect losses through damage to the brand. For many of my

clients, the direct cost of downtime exceeds $100,000 per hour.

2. That phrase has always bothered me. As an engineer, I expect it to either be “24 by

365” or be “24 by 7 by 52.”

PRAGMATIC ARCHITECTURE 18

In one year the difference between 98% uptime and 99.99% uptime

adds up to more than $17 million.

Imagine adding $17 million to the

bottom line just through better design!

During the hectic rush of the development project, you can easily make

decisions that optimize development cost at the expense of operational

cost. This makes sense only in the context of the project team being

measured against a ﬁxed budget and delivery date. In the context of the

organization paying for the software, it’s a bad choice. Systems spend

much more of their life in operation than in development—at least, the

ones that don’t get canceled or scrapped do. Avoiding a one-time cost

by incurring a recurring operationalcostmakesnosense.Infact,the

opposite decision makes much moreﬁnancialsense.Ifyoucanspend

$5,000 on an automated build and release system that avoids down-

time during releases, the company will avoid $200,000.

Ithinkthat

most CFOs would not mind authorizing an expenditure that returns

4,000% ROI.

Don’t avoid one-time

development expenses

at the cost of recurring

operational expenses.

Design and architecture decisions are also

ﬁnancial decisions. These choices must be

made with an eye toward their implementation

cost as well as their downstream costs. The

fusion of technical and ﬁnancial viewpoints is

one of the most important recurring themes in

this book.

1.6 Pragmatic Architecture

Two divergent sets of activities both fall under the term architecture.

One type of architecture strives toward higher levels of abstraction that

are more portable across platforms and less connected to the messy

details of hardware, networks, electrons, and photons. The extreme

for m of this approach results in the “ivory tower”—a Kubrickesque

clean room, inhabited by aloof gurus, decorated with boxes and arrows

on every wall. Decrees emerge from the ivory tower and descend upon

the toiling coders. “Use EJB container-managed persistence!” “All UIs

shall be constructed with JSF!” “All that is, all that was, and all that

3. At an average $100,000 per hour, the cost of downtime for a tier-1 retailer.

4. This assumes $10,000 per release (labor plus cost of planned downtime), four releases

per year, and a ﬁve-year horizon. Most companies would like to do more than four releases

per year, but I’m being conservative.

PRAGMATIC ARCHITECTURE 19

shall ever be lives in Oracle!” If you’ve ever gritted your teeth while cod-

ing something according to the “company standards” that would be ten

times easier with some other technology, then you’ve been the victim

of an ivory-tower architect. I guarantee that an architect who doesn’t

bother to listen to the coders on the team doesn’t bother listening to the

users either. You’ve seen the result: users who cheer when the system

crashes, because at least then they can stop using it for a while.

In contrast, another breed of architect rubs shoulders with the coders

and might even be one. This kind of architect does not hesitate to

peel back the lid on an abstractionortojettisononeifitdoesnot

ﬁt. This pragmatic architect is more likely to discuss issues such as

memory usage, CPU requirements, bandwidth needs, and the beneﬁts

and drawbacks of hyperthreading and CPU bonding.

The ivory-tower architect most enjoys an end-state vision of ringing

crystal perfection, but the pragmaticarchitectconstantlythinksabout

the dynamics of change. “How can we do a deployment without reboot-

ing the world?” “What metrics do we need to collect, and how will we

analyze them?” “What part of the system needs improvement the most?”

When the ivory-tower ar chitect is done, the system will not admit any

improvements; each part will be perfectly adapted to its role. Contrast

that to the pragmatic architect’s creation, in which each component is

good enough for the current stresses—and the architect knows which

ones need to be replaced dependingonhowthestressfactorschange

over time.

If you’re already a pragmatic architect, then I’ve got chapters full of

powerful ammunition for you. If you’re an ivory-tower architect—and

you haven’t already stopped reading—then this book might entice you

to descend through a few levels of abstraction to get back in touch with

that vital intersection of software, hardware, and users: living in pro-

duction. You, your users, and your company will all be much happier

when the time comes to ﬁnally release it!

剩余349页未读，继续阅读

chekai1985

粉丝: 0
资源: 1

《发布它》：打造生产级Web应用的深度指南

Release It! Design and Deploy Production-Ready Software

Pragmatic Bookshelf - Release It! Design and Deploy Production Ready Software.pdf

release-it：version自动进行版本控制和包发布

Release It Design And Deploy Production Ready Software

Release It! - Design and Deploy Production-Ready Software 2nd

Release It!-Design and Deploy Production-Ready Software-2007

《Release It!》：敏捷开发实战指南，打造生产级软件

release-it：Github在Github存储库中利用release-it的操作

IT6802 Register List Release_RegisterList_release_voyagevss_IT68

release

最新资源