Raft算法：保障分布式系統共識的穩健之道
1. 什么是Raft算法？Raft 是英文”Reliable、Replicated、Redundant、And Fault-Tolerant”（“可靠、可復制、可冗余、可容錯”）的首字母縮寫。Raft算法是一種用于在分布式系統
12月5日消息，2023亞馬遜云科技 re:lnvent 的壓軸仍然是亞馬遜公司副總裁兼首席技術官 Werner Vogels 的演講。
作為亞馬遜CTO，Werner Vogels可謂是亞馬遜云科技的靈魂人物，也是云計算領域知名的頂級專家。
Werner Vogels 擁有計算機博士學位，在加入亞馬遜之前，Werner Vogels 是一名學者，曾在康奈爾大學進行了十年的研究科學工作，并建立了大規模的分布式系統。
2004年Werner Vogels 加入亞馬遜擔任系統研究總監，2005年1月被任命為CTO和副總裁至今。
今年是Werner Vogels 第十二次在re:lnvent 亮相。
在今年的演講中，Werner Vogels 鄭重向現場和線上的架構師們推薦了自己寫的《The Frugal Architect》（《云架構節儉之道》）這本“新書”。
亞馬遜公司副總裁兼首席技術官 Werner Vogels
其實《The Frugal Architect》只有短短7頁，每頁對應了Werner Vogels 想要強調的一項法則，為架構師和開發者們提供了有關架構設計、衡量、優化的規范準則教程。
在全球企業都在強調“降本”的大環境中，理解《The Frugal Architect》可謂正合時宜。
以下為《The Frugal Architect》的內容：
LAW I.
Make Cost a Non-functional Requirement.
A non-functional requirement specifies criteria that can be used to judge the operation of a system, rather than specific features or functions. Examples are accessibility, availability, scalability, security, portability, maintainability, and compliance. What often goes overlooked is cost.
Companies can fail because they don’t consider cost at every stage of the business – from design to development to operation – or because they’re not measuring it properly. The math is simple: if costs are higher than your revenue, your business is at risk.
By considering cost implications early and continuously, systems can be designed to balance features, time-to-market, and efficiency. Development can focus on maintaining lean and efficient code. And operations can fine-tune resource usage and spending to maximize profitability.
法則I
使成本成為非功能性需求。
非功能性需求指定了可用于判斷系統運行的標準，而不是特定的特征或功能。示例包括可訪問性、可用性、可擴展性、安全性、可移植性、可維護性和法規遵從性。經常被忽視的是成本。
公司可能會失敗，因為他們沒有考慮到業務的每個階段——從設計到開發再到運營——或者因為他們沒有正確地衡量成本。數學很簡單：如果成本高于收入，你的企業就面臨風險。
通過盡早和持續地考慮成本影響，可以設計系統來平衡功能、上市時間和效率。開發可以專注于維護精簡高效的代碼。運營可以微調資源使用和支出，以最大限度地提高盈利能力。
LAW II.
Systems that Last Align Cost to Business.
The durability of a system depends on how well its costs are aligned to the business model. When designing and building systems, we must consider the revenue sources and profit levers. It’s important to find the dimension you’re going to make money over, then make sure the architecture follows the money.
For example, in e-commerce, that dimension might be the number of orders. When orders go up, infrastructure and operation costs rise. And that’s okay, because if your system is architected well, you can start to exploit economies of scale. What’s important is that infrastructure costs have a measurable impact on the business.
As builders, we need to think about revenue – and use that knowledge to inform our choices. Because growth at all costs leads to a trail of destruction.
法則II
最后使成本與業務保持一致的系統。
系統的持久性取決于其成本與商業模式的一致性。在設計和構建系統時，我們必須考慮收入來源和利潤杠桿。重要的是要找到你將要賺錢的維度，然后確保架構遵循資金。
例如，在電子商務中，該維度可能是訂單數量。當訂單增加時，基礎設施和運營成本就會上升。這沒關系，因為如果你的系統架構良好，你就可以開始利用規模經濟。重要的是，基礎設施成本對業務有著可衡量的影響。
作為構建者，我們需要考慮收入，并利用這些知識為我們的選擇提供信息。因為不惜一切代價的增長會帶來毀滅的痕跡。
LAW III.
Architecting is a Series of Trade-offs.
In architecture, every decision comes with a trade-off. Cost, resilience, and performance are non-functional requirements that are often at tension with each other.
As the saying goes, “Everything fails, all the time.” Being able to defend against failure means investing in resilience, but performance may pay the price.
It’s crucial to find the right balance between your technical and business needs – to find the sweet spot that aligns with your risk tolerance and budget. Remember, frugality is about maximizing value, not just minimizing spend. And to do that, you need to determine what you’re willing to pay for.
法則 III
在持續的取舍與權衡中搭建架構。
在體系結構中，每一個決策都伴隨著一種權衡。成本、彈性和性能是非功能性需求，它們往往相互矛盾。
俗話說：“一切都會失敗。”能夠抵御失敗意味著投資于韌性，但業績可能會付出代價。
在您的技術和業務需求之間找到正確的平衡至關重要——找到與您的風險承受能力和預算相一致的最佳點。記住，節儉是價值最大化，而不僅僅是支出最小化。要做到這一點，你需要確定你愿意為什么付費。
LAW IV.
Unobserved Systems Lead to Unknown Costs.
Without careful observation and measurement, the true costs of operating a system remain invisible. Like a utility meter tucked away in a basement, lack of visibility enables wasteful habits. Making meters more visible can profoundly shift behaviors.
Though observation requires investment, not implementing adequate monitoring is shortsighted. The adage warns, “If you can’t measure it, you can’t manage it.” Tracking utilization, spending, errors, and more, is crucial for cost management.
When critical cost metrics are placed front-and-center before engineers and their business partners, more sustainable practices emerge organically. Ongoing inspection lets you spot excess spend and tune operations to trim expenses. The return on investment in observability typically far outweighs the expense.
Most importantly, keeping costs in the forefront encourages sustainable practices.
法則IV
未觀測到的系統帶來未知的成本
如果沒有仔細的觀察和衡量，運行一個系統的真正成本仍然是看不見的。就像藏在地下室的公用事業計量表一樣，缺乏可見性會導致浪費的習慣。使儀表更顯眼可以深刻地改變行為。
盡管觀察需要投資，但不進行充分的監測是短視的。這句格言警告說，“如果你不能衡量它，你就無法管理它。”跟蹤利用率、支出、錯誤等對成本管理至關重要。
當關鍵成本指標被放在工程師及其業務合作伙伴之前的首要位置和中心位置時，更可持續的實踐就會有機地出現。持續的檢查可以讓您發現多余的支出，并調整運營以削減開支。可觀測性的投資回報通常遠遠超過支出。
最重要的是，將成本保持在首位會鼓勵可持續的做法。
LAW V.
Cost Aware Architectures Implement Cost Controls.
The essence of frugal architecture is robust monitoring combined with the ability to optimize costs. Well-designed systems allow you to take action on opportunities for improvement. For this to work, decompose applications into tunable building blocks.
A common approach is tiering components by criticality. Tier 1 components are essential; optimize regardless of cost. Tier 2 components are important but can be temporarily scaled down without major impact. Tier 3 components are “nice-to-have”; make them low-cost and easily controlled.
Defining tiers enables trade-offs between cost and other requirements. Granular control over components optimizes both cost and experience. Infrastructure, languages, databases should all be tunable. Architect and build systems with revenue and profit in mind. Cost optimization must be measurable and tied to business impact.
法則V
通過成本感知的架構實施成本控制。
節儉架構的本質是穩健的監控與優化成本的能力相結合。精心設計的系統使您能夠抓住改進的機會采取行動。要實現這一點，請將應用程序分解為可調的構建塊。
一種常見的方法是按關鍵程度對組件進行分層。一級組件是必不可少的；優化而不考慮成本。二級組件很重要，但可以暫時縮減，不會產生重大影響。第3層組件是“很好擁有的”；使其成本低且易于控制。
定義層可以在成本和其他需求之間進行權衡。對組件的精細控制可優化成本和體驗。基礎設施、語言和數據庫都應該是可調的。在設計和構建系統時考慮到收入和利潤。成本優化必須是可衡量的，并與業務影響掛鉤。
LAW VI.
Cost Optimization is Incremental.
The pursuit of cost efficiency is an ongoing journey. Even after deployment, we must revisit systems to incrementally improve optimization. The key is continually questioning and diving deeper. Programming languages provide profiling tools to analyze code performance, and while these require setup and expertise, they enable granular analyses that can lead to changes that shave milliseconds. What may seem like small optimizations accumulate into large savings at scale.
In operations, most time is spent running existing systems. There are opportunities to profile resource usage and identify waste reduction. At Amazon, we continuously monitor services in production to understand patterns and trim inefficiencies. Frugality takes persistence – by incrementally reducing latencies and infrastructure costs, we can optimize the cost to serve.
There is always room for improvement… if we keep looking. The savings we reap today fund innovation for tomorrow.
法則VI
成本優化是漸進的
追求成本效益是一個持續的過程。即使在部署之后，我們也必須重新訪問系統以逐步改進優化。關鍵是不斷質疑和深入研究。編程語言提供了分析代碼性能的分析工具，雖然這些工具需要設置和專業知識，但它們可以實現細粒度分析，從而導致縮短幾毫秒的更改。看似微小的優化會大規模地積累成巨大的節約。
在操作中，大部分時間都花在運行現有系統上。有機會了解資源使用情況并確定廢物減少情況。在亞馬遜，我們持續監控生產中的服務，以了解模式并降低效率。節儉需要持久性——通過逐步減少延遲和基礎設施成本，我們可以優化服務成本。
如果我們繼續尋找，總有改進的空間。我們今天節省下來的資金用于明天的創新
LAW VII.
Unchallenged Success Leads to Assumptions.
When software teams achieve significant success without facing major failures or roadblocks, complacency can set in. There is a dangerous tendency to become overconfident in the methods, tools, and practices that led to those wins.
Software teams often fall into the trap of assuming their current technologies, architectures, or languages will always be the best choice, simply because they have worked in the past. This can create a false sense of security that discourages questioning the status quo or exploring new options which could be more efficient, cost-effective, or scalable.
You see this frequently when it comes to programming languages. “We’re a Java shop” is a phrase I’ve heard too often – and it can stifle innovation. Unchallenged success breeds complacency through assumptions. We must always look for ways to question, optimize and improve.
As Grace Hopper famously stated, one of the most dangerous phrases in the English language is: “We’ve always done it this way.”
法則VII
走出慣性，遠離盲目
當軟件團隊在沒有面臨重大失敗或障礙的情況下取得重大成功時，就會產生自滿情緒。對導致這些勝利的方法、工具和實踐有過度自信的危險傾向。
軟件團隊經常陷入這樣的陷阱，即認為他們當前的技術、體系結構或語言永遠是最好的選擇，僅僅因為他們過去是這樣工作的。這可能會產生一種虛假的安全感，阻礙人們質疑現狀或探索更高效、更具成本效益或可擴展的新選擇。
當涉及到編程語言時，您經常會看到這種情況。“我們是一家Java商店”是我經常聽到的一句話——它會扼殺創新。不受挑戰的成功通過假設滋生自滿情緒。我們必須始終尋找質疑、優化和改進的方法。
正如Grace Hopper的名言，英語中最危險的短語之一是：“我們一直都是這樣做的。”
本文鏈接：http://www.tebozhan.com/showinfo-21-38491-0.html架構師們，亞馬遜CTO喊你看看這本書
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號