Open emily40830 opened 9 months ago
心得:
疑問:
服務架構演進
只需要認識服務的 interface 就可以使用服務
所有功能都依賴同一個Process
每個服務都是獨立的個體
所有 Component 只能透過 Core System 呼叫
透過 Event 來傳遞訊息
Event-Driven Architecture 中的 Event Processor被拆分成多個 services
- Organized around Business Capability
- Decentralized Governance
- Componentization via Services
- Products not Projects
- Decentralized Data Management
- Smart Endpoint and Dumb Pipe
- Design for Failure
- Evolutionary Design
- Infrastructure Automation
Serverless
演進中的架構 - 服務架構演進史
原始分佈式: 由於硬體需求不足以負荷工作,所以尋找分布式的可能性,卻由於其他硬體因素(網路)而失敗。這時候沒有複雜的系統或是規範,提出了純粹的設計哲學 - Simplicity of both the interface and the implementation 。
單體系統: 單體系統的所有調用都是 程序間調用(Inter-Process Communication, IPC),而能在相同硬體下展現最傑出的效能,但由於硬體垂直升級的難易度遠大於橫向展開,所以無法承擔後續成長的業務。
SOA: SOA 在服務架構上提出了很激進、有野心的想法,設計哲學是"更具體、更系統"。但這兩點思想導致了使用 SOA 的學習成本過高和使用情境受限,"过于严格的规范定义带来过度的复杂性" 讓 SOA 無法持續流行。
微服務: 和 SOA 提出整套解決方案相反,微服務強調 "九个核心的业务与技术特征" 而不提供具體架構/方案,進一步導向多家公司提出不同的解決方案。進一步讓架構師有不同的選型,也讓架構師"对架构能力要求已提升到史无前例的程度"。
後微服務: 由於 容器化(Docker) 以及 集群管理(k8s) 的發展讓硬體的靈活度提升,以 "分布式" 的方案 "让软件得以只专注业务,真正“围绕业务能力构建”团队与产品"。
無服務器: “后端即服务”(Backend as a Service,BaaS)、“函数即服务”(Function as a Service,FaaS),無服務器則是以 "非分佈式(雲端式)" 的將 "軟體" 和 "架構" 抽離。
吃 🍉 為主,隨筆撰寫
所以,当我们在讨论单体系统的缺陷的时候,必须基于软件的性能需求超过了单机,软件的开发人员规模明显超过了 “2 Pizza Teams” 范畴的前提下,这样才有讨论的价值。
通常 "2 Pizza Team" 是指用兩份比薩能餵飽的團隊規模 (約 6 ~ 12 人),這也是軟體開發的理想管理規模大小。而一項任務的參與人數,會導致溝通成本呈指數成長註 1,在 Scrum Guile 對於團隊人數的建議也是在 10 人以下 註 2。
實踐上會是一組 "2 Pizza Team" 開發/維護一組微服務,微服務的粒度上限需考慮 "2 Pizza Team" 能於單一開發週期的產出能力考量,如同 Conway's Law 所約束:「設計系統的架構受制於產生這些設計的組織的溝通結構」。
但如果你家楼下开的小卖部,爸、妈加儿子,再算上看家的中华田园犬小黄,一共也就只有四名员工,也去追求 “先进管理”,来划分仓储部、采购部、库存管理部……的话,那纯粹是给自己找麻烦。
個人認為「微服務」這個方法論是沒問題的,但需要考量到組織架構,小團隊導入微服務純粹是自找麻煩。如同 Sociotechnical 所定義,任何系統皆由 ”技術“ 與 ”人“ 交互結合而組成,"人" 包含組織、政治、條規、實踐、流程等元素,比起單獨從 "技術 " 或是 ”人" 的角度來觀看系統,將其兩者的交互要素結合起來,才能更真實地去瞭解系統的運行狀況。
这个核心技术特征,实际上再次强调了康威定律的重要性。它的意思是,有怎样的结构、规模和能力的团队,就会产生出对应结构、规模、能力的产品。这个结论不是某个团队、某个公司遇到的巧合,而是必然的演化结果。
不可試探你的組織架構
The first step in dealing with Conway's Law is know not to fight it.
微服务更加强调的是,在确实有必要进行技术异构的时候,一个开发团队应该能有选择“不统一”的权利。比如说,我们不应该强迫用 Node.js 去开发报表页面;要做人工智能计算的时候,也可以选择用 Python,等等。
反過來說,若沒有需求必要,個人認為一間公司應規範其程式語言甚至其技術堆疊,降低工程師的認知負擔,如同書中所提到的:
可是,微服务对架构者来说却是满满的恶意,因为它对架构能力的要求可以说是史无前例。要知道,技术架构者的第一职责就是做决策权衡,有利有弊才需要决策,有取有舍才需要权衡。如果架构者本身的知识面不足以覆盖所需要决策的内容,不清楚其中的利弊,也就不可避免地会陷入选择困难症的困境之中。
开发团队应该为软件产品的整个生命周期负责。开发者不仅应该知道软件是如何开发的,还应该知道它会如何运作、用户如何反馈,乃至售后支持工作是怎样进行的。这里服务的用户,不一定是最终用户,也可能是消费这个服务的另外一个服务。
個人視其為 DevOps 文化的實踐。
另外,尽管在分布式中,我们要想处理好一致性的问题也很困难,很多时候都没法使用传统的事务处理来保证不出现一致性问题。但是两害相权取其轻,一致性问题这些必要的代价是值得付出的。
以微服務來說有 Sagas Pattern 來解決跨微服務的交易,然而也增加了系統的複雜度,譬如開發團隊需要設計交易補償的處理流程。
如果服务需要上面的某一种功能或能力,那就应该在服务自己的 Endpoint(端点)上解决,而不是在通讯管道上一揽子处理。
然而在 API Management 的概念,會有一組 API Gateway 可以協助做身份認證授權
圖片來源: Building fine-grained authorization using Amazon Cognito, API Gateway, and IAM | AWS Security Blog
All problems in computer science can be solved by another level of indirection
—— Butler Lampson
如果問題還是沒有解決,那你可以再多加一層,然後 Sidecar Proxy 就橫空出世。
实际上,类似的情况不仅仅会在断路器上出现,服务的监控、认证、授权、安全、负载均衡等功能,都有细化管理的需求。比如,服务调用时的负载均衡,往往需要根据流量特征,调整负载均衡的层次、算法等,而 DNS 尽管能实现一定程度的负载均衡,但它通常并不能满足这些额外的需求。 所以,为了解决这一类问题,微服务基础设施很快就进行了第二次进化,引入在今天被我们叫做是 “服务网格”(Service Mesh)的 “边车代理模式”(Sidecar Proxy)。
所以“断路器”这类设施,对实际生产环境的微服务来说,并不是可选的外围组件,而是一个必须的支撑点。
Circuit Breaker 對於微服務實踐已經是必要項目了嗎...。
虽然 Spring Cloud 和 Kubernetes 的出发点不同,解决问题的方法和效果也不一样,但不容忽视的是,Kubernetes 的确提供了一条全新的、前途更加广阔的解题思路。
只好把 Vicent 哥的簡報再請出來了: JCConf 2020 Vincent Huang - Google 簡報
云原生时代追求的目标,跟此前微服务时代中追求的目标相比,并没有什么本质的改变,它们都是通过一系列小型服务去构建大型系统。在服务架构演进的历史进程中,我更愿意把“云原生时代”称为“后微服务时代”。
若以服務的角度來看,的確追求的目標並無本質上的改變,然而 "雲端原生" 涉及許多不同領域,譬如解決了傳統 IT 操作模型的缺點,包括難以創建可擴展、容錯、自我修復的應用程式,以及低效的資源利用率等。單純用 "後微服務時代" 此一名詞難以含括其他領域的內容,簡單來說 "雲端原生" 與 "微服務" 雖有共同之處,但兩者的概念不同,可參考 CNCF 的中文定義:
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。
相互之間交流的情況更糟一些。如果任務的每個部分必須分別和其他部分單獨協作,則工作量按照 n(n-1)/2 遞增。一對一交流的情況下,三個人的工作量是兩個人的三倍,四個人則是兩個人的六倍。而對於需要在三四個人之間召開會議、進行協商、一同解決的問題,情況會更加惡劣。所增加的用於溝通的工作量可能會完全抵消對原有任務分解所產生的作用。
—— 《人月神話:軟體專案管理之道》
Scrum Team 規模足夠小以保持靈活性,同時足夠大以便可以在 Sprint 內完成重要的工作,通常人數在 10 人以下。一般而言,我們發現越小的團隊溝通越好,生產力更高。如果 Scrum Teams 變得太大,他們應該考慮重新組織為多個有凝聚力的 Scrum Team,每個團隊還是專注在同一個產品,因此,他們應該有著相同的 Product Goal、Product Backlog 和 Product Owner。
—— 《Scrum Guides》
作者按照自己的整理把整個架構的發展歷史分成六個時期
原始分散式架構時期:這個時期有很多分散式系統的嘗試,催生了非常多之後仰賴的重要基礎(像是 DCE/RPC, DCE/DFS)。由於是發展初期很多技術或標準都還不足以完整解決問題,受到很多阻力,以致單體架構是當時最穩定的選擇
單體架構時期:為了和微服務區隔而生的名詞,是最早出現的架構風格。 特性:性能好,但隔離性差,如果單體內某個部件故障的話,很容易擴散到整個單體,沒辦法有效控管。
ps. 採用程序內呼叫,沒有跨程序間通信的問題
SOA 服務導向時期:為了區隔,開始有不同的解決方案 (煙囪式架構、插件式架構、事件驅動架構)。另外本時期的代表物為 SOAP 協議,企圖以非常全面的標準涵蓋所有狀況,但因為架構過於複雜,並沒有辦法被大家所接受,於是被時代的洪流沖散了
微服務時期:2014 年的文章 "Microservices - a definition of this new architectural term" 揭開了序幕,至此和 SOA 劃開界線。總共有九個重要特性,影響了之後的架構發展
擺脫 SOA 束縛的架構,開始蓬勃發展
後微服務時期:虛擬化、容器化技術成為推手,k8s 最終成為大家接收的事實標準 (docker 也不得不低頭)
無服務時期:未知的新領域,大家還在持續探索。代表概念:BaaS (Backend as a Service), FaaS (Function as a Service)
剛接觸概念,技術名詞有點多,先抓住大概的發展脈絡
軟體架構流變
服務架構隨硬體限制及軟體要求一同發展,不同情境各有適合的架構。
硬體性能有限⇒原始分布式
→硬體性能提升⇒單體
→軟體規模增加⇒無服務
$~~~~~~~~$⇒面向服務架構(SOA)
→SOA對一般應用情境過於複雜⇒微服務
→容器技術發展⇒後微服務(雲原生)
原始分布式
單體
面向服務架構(SOA)
微服務
後微服務
無服務
暫無
沒空能寫成 markdown, 先貼個筆記版 https://app.heptabase.com/w/9566bffb82a5be35984b539a17ba39d2e59860ca4787969066bcd8ccde6fb4d5?id=79aa75a6-7536-4c57-a561-a2d861ecb768 😿
問題集:
服務架構演進史 請以 submit comment 寫學習要點