《Y演进式架构》：应对快速变化的技术指南

需积分: 10 85 浏览量更新于2024-07-14 收藏 5.09MB PDF 举报

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

领优惠券(最高得80元）

《演进式架构：支持持续变革》（英文版）是一本由Neal Ford、Rebecca Parsons 和 Patrick Kua 合著的专业书籍。该书深入探讨了在快速变化的IT环境中如何构建能够适应并促进持续创新的架构。作者们结合自身丰富的经验和深厚的专业知识，提出了一种动态的、灵活的方法论，旨在帮助读者理解和实践如何在不断演进的技术栈中保持系统的稳定性和可扩展性。本书的主题核心是"Evolutionary Architectures"，它强调的是在当前IT领域中，由于技术进步和业务需求的不确定性，传统的静态架构设计已经不能满足需求。演进式架构更倾向于迭代和渐进式改进，鼓励系统组件之间的松耦合、模块化和可替换性，使得系统能够随着时间和环境的变化而不断演化，而不是一次性设计完成就不再改变。书中涵盖了关键概念和技术，如微服务架构、云计算、DevOps原则、敏捷开发方法以及DevOps文化等，这些都在书中得到了详细的阐述和实践指导。作者们提供了实用的策略和最佳实践，帮助读者设计出能够应对市场和技术波动，以及内部组织结构变化的灵活架构。《演进式架构》不仅适用于软件开发团队的领导者，也适合架构师、开发人员和IT管理人员，他们需要在不断变化的环境中保持竞争力和创新能力。通过阅读本书，读者可以提升对架构演进的理解，学会如何在挑战与机遇并存的环境中进行有效决策，并为组织构建一个可持续发展的技术基石。全书分为多个章节，分别剖析了架构设计的原则、实施步骤、案例研究以及面临的挑战和应对策略。此外，本书还包含了丰富的在线资源链接，包括Allitebooks.com和RejoiceBlog.com，方便读者获取更多相关资料和社区交流。版权信息显示，本书于2017年出版，享有所有权利，由O'Reilly Media Inc.发行。印刷版本和在线版本均可获取，读者可以通过指定渠道获得教育、商业或销售推广用途的许可。该书的编辑和制作团队名单也列在最后，展示了专业团队对内容品质的承诺。《演进式架构：支持持续变革》是一本具有实战价值的指南，为IT专业人士提供了解决动态环境中架构管理问题的宝贵工具和思考框架。通过深入学习和应用书中的理念和方法，读者将能够更好地应对行业变革，确保组织的IT架构始终保持在竞争优势的前沿。

资源详情

资源推荐

Figure 1-1. e entire scope of architecture encompasses requirements plus “-ilities”

As seen in Figure 1-1, business and domain requirements exist alongside other archi‐

tecture concerns (defined by architects). This includes a wide range of external fac‐

tors that can alter the decision process on what and how to build a software system.

For a sampling, check out the list in Table 1-1:

Table 1-1. Partial list of “-ilities”

accessibility accountability accuracy adaptability administrability

aordability agility auditability autonomy availability

compatibility composability congurability correctness credibility

customizability debugability degradability determinability demonstrability

dependability deployability discoverability distributability durability

eectiveness eciency usability extensibility failure transparency

fault tolerance delity exibility inspectability installability

integrity interoperability learnability maintainability manageability

mobility modiability modularity operability orthogonality

portability precision predictability process capabilities producibility

provability recoverability relevance reliability repeatability

reproducibility resilience responsiveness reusability robustness

safety scalability seamlessness self-sustainability serviceability

securability simplicity stability standards compliance survivability

sustainability tailorability testability timeliness traceability

When building software, architects must determine the most important of these

“-ilities.” However, many of these factors oppose one another. For example, achieving

both high performance and extreme scalability can be difficult because achieving

2 | Chapter 1: Software Architecture

http://www.rejoiceblog.com/

1 Clarke, G. M., Gross, S., Matthews, M., Catling, P. C., Baker, B., Hewitt, C. L., Crowther, D., & Saddler, S. R.

2000, Environmental Pest Species in Australia, Australia: State of the Environment, Second Technical Paper

Series (Biodiversity), Department of the Environment and Heritage, Canberra.

both requires a careful balance of architecture, operations, and many other factors.

As a result, the necessary analysis in architecture design and the inevitable clash of

competing factors requires balance, but balancing the pros and cons of each architec‐

tural decision leads to the tradeos so commonly lamented by architects. In the last

few years, incremental developments in core engineering practices for software devel‐

opment have laid the foundation for rethinking how architecture changes over time

and on ways to protect important architectural characteristics as this evolution

occurs. This book ties those parts together with a new way to think about architecture

and time.

We want to add a new standard “-ility” to software architecture—evolvability.

Evolutionary Architecture

Despite our best efforts, software becomes harder to change over time. For a variety

of reasons, the parts that comprise software systems defy easy modification, becom‐

ing more brittle and intractable over time. Changes in software projects are usually

driven by a reevaluation of functionality and/or scope. But another type of change

occurs outside the control of architects and long-term planners. Though architects

like to be able to strategically plan for the future, the constantly changing software

development ecosystem makes that difficult. Since we can’t avoid change, we need to

exploit it.

How Is Long-term Planning Possible When Everything Changes All

the Time?

In the biological world, the environment changes constantly from both natural and

man-made causes. For example, in the early 1930s, Australia had problems with cane

beetles, which rendered the production and harvesting sugar cane crops less profita‐

ble. In response, in June 1935, the then Bureau of Sugar Experiment Stations intro‐

duced a predator, the cane toad, previously only native to south and middle America.

After being bred in captivity a number of young toads were released in North

Queensland in July and August 1935. With poisonous skin and no native predators,

the cane toads spread widely; there are an estimated 200 million in existence today.

The moral: introducing changes to a highly dynamic (eco)system can yield unpre‐

dictable results.

The software development ecosystem consists of all the tools, frameworks, libraries,

and best practices—the accumulated state of the art in software development. This

Evolutionary Architecture | 3

http://www.rejoiceblog.com/

ecosystem forms an equilibrium—much like a biological system—that developers can

understand and build things within. However, that equilibrium is dynamic—new

things come along constantly, initially upsetting the balance until a new equilibrium

emerges. Visualize a unicyclist carrying boxes: dynamic because she continues to

adjust to stay upright and equilibrium because she continues to maintain balance. In

the software development ecosystem, each new innovation or practice may disrupt

the status quo, forcing the establishment of a new equilibrium. Metaphorically, we

keep tossing more boxes onto the unicyclist’s load, forcing her to reestablish balance.

In many ways, architects resemble our hapless unicyclist, constantly both balancing

and adapting to changing conditions. The engineering practices of Continuous Deliv‐

ery represent such a tectonic shift in the equilibrium: Incorporating formerly siloed

functions such as operations into the software development lifecycle enabled new

perspectives on what change means. Enterprise architects can no longer rely on static

5-year plans because the entire software development universe will evolve in that

timeframe, rendering every long-term decision potentially moot.

Disruptive change is hard to predict even for savvy practitioners. The rise of contain‐

ers via tools like Docker is an example of an unknowable industry shift. However, we

can trace the rise of containerization via a series of small, incremental steps. Once

upon a time, operating systems, application servers, and other infrastructure were

commercial entities, requiring licensing and great expense. Many of the architectures

designed in that era focused on efficient use of shared resources. Gradually, Linux

became good enough for many enterprises, reducing the monetary cost of operating

systems to zero. Next, DevOps practices like automatic machine provisioning via

tools like Puppet or Chef made Linux operationally free. Once the ecosystem became

free and widely used, consolidation around common portable formats was inevitable;

thus, Docker. But containerization couldn’t have happened without all the evolution‐

ary steps leading to that end.

The programming platforms we use exemplify constant evolution. Newer versions of

a programming language offer better application programming interfaces (APIs) to

improve the flexibility or applicability toward new problems; newer programming

languages offer a different paradigm and different set of constructs. For example, Java

was introduced as a C++ replacement to ease the difficulty of writing networking

code and to improve memory management issues. When we look at the past 20 years,

we observe that many languages still continually evolve their APIs while totally new

programming languages appear to regularly attack newer problems. The evolution of

programming languages is demonstrated in Figure 1-2.

4 | Chapter 1: Software Architecture

http://www.rejoiceblog.com/

Figure 1-2. e evolution of popular programming languages

Regardless of which particular aspect of software development—the programming

platform, languages, the operating environment, persistence technologies, and so on

—we expect constant change. Although we cannot predict when changes in the tech‐

nical or domain landscape will occur, or which changes will persist, we know change

is inevitable. Consequently, we should architect our systems knowing the technical

landscape will change.

If the ecosystem constantly changes in unexpected ways, and predictability is impos‐

sible, what is the alternative to fixed plans? Enterprise architects and other developers

must learn to adapt. Part of the traditional reasoning behind making long-term plans

was financial; software changes were expensive. However, modern engineering prac‐

tices invalidate that premise by making change less expensive by automating formerly

manual processes and other advances such as DevOps.

For years, many smart developers recognized that some parts of their systems were

harder to modify than others. That’s why

soware architecture is defined as the “parts

hard to change later.” This convenient definition partitioned the things you can mod‐

ify without much effort from truly difficult changes. Unfortunately, this definition

also evolved into a blind spot when thinking about architecture: Developers’ assump‐

tion that change is difficult becomes a self-fulfilling prophecy.

Several years ago, some innovative software architects revisited the “hard to change

later” problem in a new light: what if we build changeability into the architecture? In

other words, if ease of change is a bedrock principle of the architecture, then change is

no longer difficult. Building evolvability into architecture in turn allows a whole new

set of behaviors to emerge, upsetting the dynamic equilibrium again.

Even if the ecosystem doesn’t change, what about the gradual erosion of architectural

characteristics that occurs? Architects design architectures, but then expose them to

Evolutionary Architecture | 5

http://www.rejoiceblog.com/

the messy real world of implementing things atop the architecture. How can architects

protect the important parts they have defined?

Once I’ve Built an Architecture, How Can I Prevent It from Gradually

Degrading Over Time?

An unfortunate decay, often called bit rot, occurs in many organizations. Architects

choose particular architectural patterns to handle the business requirements and

“-ilities,” but those characteristics often accidentally degrade over time. For example,

if an architect has created a layered architecture with presentation at the top, persis‐

tence at the bottom, and several layers in between, developers who are working on

reporting will often ask permission to directly access persistence from the presenta‐

tion layer, bypassing the other layers, for performance reasons. Architects build layers

to isolate change. Developers then bypass those layers, increasing coupling and inva‐

lidating the reasoning behind the layers.

Once they have defined the important architectural characteristics, how can archi‐

tects protect those characteristics to ensure they don’t erode? Adding evolvability as an

architectural characteristics implies protecting the other characteristics as the system

evolves. For example, if an architect has designed an architecture for scalability, she

doesn’t want that characteristic to degrade as the system evolves. Thus, evolvability is

a meta-characteristic, an architectural wrapper that protects all the other architectural

characteristics.

In this book, we illustrate that a side effect of an evolutionary architecture is mecha‐

nisms to protect the important architecture characteristics. We explore the ideas

behind continual architecture: building architectures that have no end state and are

designed to evolve with the ever-changing software development ecosystem, and

including built-in protections around important architectural characteristics. We

don’t attempt to define software architecture in totality; many other definitions exist.

We focus instead on extending current definitions to adding time and change as first-

class architectural elements.

Here is our definition of evolutionary architecture:

An evolutionary architecture supports guided, incremental change across multiple

dimensions.

Incremental Change

Incremental change describes two aspects of software architecture: how teams build

software incrementally and how they deploy it.

During development, an architecture that allows small, incremental changes is easier

to evolve because developers have a smaller scope of change. For deployment, incre‐

6 | Chapter 1: Software Architecture

http://www.rejoiceblog.com/

剩余189页未读，继续阅读

max18

粉丝: 5
资源: 25

《Y演进式架构》：应对快速变化的技术指南

藏经阁-腾讯包管理方案演进.pdf

腾讯QQ后台架构演进：支撑1.4亿在线的秘密

前端与后端分离：Web应用架构演进史与Node.js角色

4-8+快手大数据混部架构演进之路.pdf

演进式架构 翻译 book

thoughtworks现代企业架构框架白皮书_v4.pdf

移动通信系统的空口演进.pdf

好买财富基金交易系统的分布式架构演进 pdf

云原生架构从技术演进到最佳实践pdf

等级保护2.0时代的云等保合规与云安全基本要求解读v2.3_20171220.pdf

compactpci serial specification.pdf

聊聊架构pdf完整版

learnopenglcn .pdf

SD-WAN架构的演进

lte-umts长期演进理论与实践 pdf

支付宝的高可用与容灾架构演进

随着分布式系统、云计算等技术的快速发展，软件架构从单体式到垂直式，从分布式到微服务，

河道渠道水流演进代码

最新资源

演进式架构翻译 book