第一章：服務架構演進史 學習要點

[emily40830]

服務架構演進史
請以 submit comment 寫學習要點

[shihgangliu]

• 心得：

  1. 原始分布式时代：因為早期單台計算機效能不足進而衍生出利用多台計算機共同協作衍生出的方案。而 OSF 也在此時制定了 DCE 的分散式技術標準。但是分布式所衍生出了複雜環境反而讓 Kely Brown 留下了一句至今也受用的一句話「某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果」。
  2. 單體系統時代：容易開發、測試、部署，且不會發生 IPC。不是不可拆分的單一巨型程式，而是由同一技術平台不同組件所構成的單層軟件。所以單體架構的真正缺陷不是拆分，而是一但某一個組件出了問題，可能會造成全局性的影響，並且難以做到局部更新。
  3. SOA 時代：即使在現在仍然是很主流的一種架構模式，將各個業務切割成不同的服務，讓彼此的溝通著重在業務邏輯上，至於實作細節則可以應不同情境而定。（其實還不是很懂和微服務的差別）
  4. 微服務架構：是一種 SOA 的變體形式。以我司來說蠻像在分散治理，各個不同的功能有不同的技術選型但又會盡量減少溝通的成本。裡面我覺得有很重要的一點，每有任何服務是不能報廢的，而是隨著時代演進可以不斷的升級。
  5. 後微服務時代：從軟體層的切割到軟硬一體拆分架構。特別是 K8S 的出現，讓開發者可以專注在業務邏輯，其它微服務的需求慢慢可以在其他元件上解決。
  6. 無服務時代：無服務的特點是開發者不需要考慮後端組件，可以隨取隨用。但目前應用場景還有現，比較適合 job 型態的服務。

• 疑問：

  1. 
     所以一個系統只要有 worker 即使所有元件在同一個 repo 下就不算單體架構了？

[HuaYuan-Tseng]

• 摘要筆記連結：Link
• 我的疑問：
  1. 在微內核架構中有提到：該架構假設系統中各個插件模塊之間是互不認識的，這一前提假設在許多場景中（如企業訊息系統或互聯網應用等等）都並不成立。我很好奇為什麼不成立？有什麼實際案例的例子嗎？
  2. 在微服務的部分有提到：整個架構需要依賴一些容錯性的設計，例如：故障檢測等等。那有沒有連這些設計或功能都出錯的時候？遇到的時候該怎麼辦？

[emily40830]

1. 軟體架構是隨著時間演進，逐步誕生不同的結果，用來解決當下特定的問題，但也因此衍生了別的問題
2. 單體架構 Monolithic Application: 適用於小型服務，易於開發、測試、部署，功能之間的調用都是在進程內調用， 不會發生進程間的通訊(Inter-Process Communication, IPC)，運行效率是最高的。
3. SOA: 為了對大型的單體系統進行拆分，每一個系統都能夠獨立部署、運行、更新。開發者嘗試了幾種方式，以下三種具代表性：煙囪式架構 (Information Silo Architecture)、微內核架構 (Microkernel Architecture)與 事件驅動架構 (Event-Driven Architecture)。當架構來到 SOA 時代，其中許多概念思想都能在現在的微服務中找到對應的身影，例如：服務之間鬆散耦合、註冊、發現、治理、隔離、編排... 這些在分布式架構提出時遇到的問題，SOA 都進行了更具體、更系統的探索。
4. 微服務：微服務是一種通過多個小型服務組合來建構單個應用的架構風格，這些服務圍繞在業務能力，而非技術標準來建構各個服務可以採用不同的程式語言、不同的數據儲存技術、運行在不同的進程中，服務採用輕量化的通訊機制和自動化部屬機制來實現通訊和維運。
5. 後微服務：在微服務時代，人們傾向用軟體的程式去解決分布式架構中出現的問題，是因為硬體的基礎設施跟不上軟構成的應用服務的靈活性。軟體可以使用指令就拆分出不同的服務，但是硬體呢？在微服務時代 Docker 就已經做為容器化的技術出現，但是早期的容器只是被簡單的視作一種可以快速啟動的服務運行環境。目的是方便程式分發部署，並未解決分布式的問題Kubernetes 2017 年 容器大戰，各家廠商紛紛加入 Kubernetes 行列。針對分布式得問題，Kubernetes 提供了基礎設施層面的解決方案
6. 無服務：以簡單著稱，主要涉及兩塊內容 : 後端設施是指資料庫、訊息佇列、日誌、存儲，等等這一類用於支撐業務邏輯運行; 函數是指業務邏輯程式碼，這裡函數的概念與粒度，都已經很接近程式編碼角度的函數了，其區別是無服務中的函數運行在雲端，不必考慮算力問題，不必考慮容量規劃，無服務的願景是讓開發者只需要純粹地專注於開發業務邏輯

[adrian-lin-1-0-0]

服務架構演進

• 原始分佈式

  只需要認識服務的 interface 就可以使用服務

• Monolithic

  所有功能都依賴同一個Process

• Service-Oriented Architecture

  • Information Silo Architecture/Information Island

    每個服務都是獨立的個體

  • Microkernel Architecture

    所有 Component 只能透過 Core System 呼叫

  • Event-Driven Architecture

    透過 Event 來傳遞訊息

• Microservices

  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

• Cloud Native

  • Autoscaling
  • Service Discovery
  • Service Configuration
  • API Gateway
  • Circuit Breaker
  • Load Balancing
  • Service Security
  • Service Monitoring

• Serverless

  • Backend as a Service
  • Function as a Service

  問題

• 什麼是 Smart Endpoint and Dumb Pipe

• Microservices 跟 SOA的差別是什麼

• Backend as a Service 跟 Function as a Service 的差別是什麼

[tuhacrt]

演進中的架構 - 服務架構演進史

• 架構的演進受到三種方面的相互影響:
  1. 性能需求/業務量
  2. 系統(運算、網路)能力
  3. 設計哲學
• "软件开发的未来不会只存在某一种“最先进的”架构风格，多种具针对性的架构风格同时并存，是软件产业更有生命力的形态。"

1. 原始分佈式: 由於硬體需求不足以負荷工作，所以尋找分布式的可能性，卻由於其他硬體因素(網路)而失敗。這時候沒有複雜的系統或是規範，提出了純粹的設計哲學 - Simplicity of both the interface and the implementation 。

2. 單體系統: 單體系統的所有調用都是 程序間調用(Inter-Process Communication, IPC)，而能在相同硬體下展現最傑出的效能，但由於硬體垂直升級的難易度遠大於橫向展開，所以無法承擔後續成長的業務。

3. SOA: SOA 在服務架構上提出了很激進、有野心的想法，設計哲學是"更具體、更系統"。但這兩點思想導致了使用 SOA 的學習成本過高和使用情境受限，"过于严格的规范定义带来过度的复杂性" 讓 SOA 無法持續流行。

4. 微服務: 和 SOA 提出整套解決方案相反，微服務強調 "九个核心的业务与技术特征" 而不提供具體架構/方案，進一步導向多家公司提出不同的解決方案。進一步讓架構師有不同的選型，也讓架構師"对架构能力要求已提升到史无前例的程度"。

5. 後微服務: 由於 容器化(Docker) 以及 集群管理(k8s) 的發展讓硬體的靈活度提升，以 "分布式" 的方案 "让软件得以只专注业务，真正“围绕业务能力构建”团队与产品"。

6. 無服務器: “后端即服务”（Backend as a Service，BaaS）、“函数即服务”（Function as a Service，FaaS），無服務器則是以 "非分佈式(雲端式)" 的將 "軟體" 和 "架構" 抽離。

[kehao-chen]

學習要點

吃 🍉 為主，隨筆撰寫

評估微服務前需將組織架構納入考量

所以，当我们在讨论单体系统的缺陷的时候，必须基于软件的性能需求超过了单机，软件的开发人员规模明显超过了 “2 Pizza Teams” 范畴的前提下，这样才有讨论的价值。

通常 "2 Pizza Team" 是指用兩份比薩能餵飽的團隊規模 (約 6 ~ 12 人)，這也是軟體開發的理想管理規模大小。而一項任務的參與人數，會導致溝通成本呈指數成長^{註 1}，在 Scrum Guile 對於團隊人數的建議也是在 10 人以下 ^{註 2}。

實踐上會是一組 "2 Pizza Team" 開發/維護一組微服務，微服務的粒度上限需考慮 "2 Pizza Team" 能於單一開發週期的產出能力考量，如同 Conway's Law 所約束：「設計系統的架構受制於產生這些設計的組織的溝通結構」。

但如果你家楼下开的小卖部，爸、妈加儿子，再算上看家的中华田园犬小黄，一共也就只有四名员工，也去追求 “先进管理”，来划分仓储部、采购部、库存管理部……的话，那纯粹是给自己找麻烦。

個人認為「微服務」這個方法論是沒問題的，但需要考量到組織架構，小團隊導入微服務純粹是自找麻煩。如同 Sociotechnical 所定義，任何系統皆由 ”技術“ 與 ”人“ 交互結合而組成，"人" 包含組織、政治、條規、實踐、流程等元素，比起單獨從 "技術 " 或是 ”人" 的角度來觀看系統，將其兩者的交互要素結合起來，才能更真實地去瞭解系統的運行狀況。

微服務的九個核心的業務與技術特徵

1. 圍繞業務能力建構（Organized around Business Capabilities）

这个核心技术特征，实际上再次强调了康威定律的重要性。它的意思是，有怎样的结构、规模和能力的团队，就会产生出对应结构、规模、能力的产品。这个结论不是某个团队、某个公司遇到的巧合，而是必然的演化结果。

不可試探你的組織架構

The first step in dealing with Conway's Law is know not to fight it.

—— <Conway's Law - Martin Fowler>

2. 分散治理（Decentralized Governance）

微服务更加强调的是，在确实有必要进行技术异构的时候，一个开发团队应该能有选择“不统一”的权利。比如说，我们不应该强迫用 Node.js 去开发报表页面；要做人工智能计算的时候，也可以选择用 Python，等等。

反過來說，若沒有需求必要，個人認為一間公司應規範其程式語言甚至其技術堆疊，降低工程師的認知負擔，如同書中所提到的：

可是，微服务对架构者来说却是满满的恶意，因为它对架构能力的要求可以说是史无前例。要知道，技术架构者的第一职责就是做决策权衡，有利有弊才需要决策，有取有舍才需要权衡。如果架构者本身的知识面不足以覆盖所需要决策的内容，不清楚其中的利弊，也就不可避免地会陷入选择困难症的困境之中。

3 透過服務來實現獨立自治的元件（Componentization via Services）

4. 產品化思維（Products not Projects）

开发团队应该为软件产品的整个生命周期负责。开发者不仅应该知道软件是如何开发的，还应该知道它会如何运作、用户如何反馈，乃至售后支持工作是怎样进行的。这里服务的用户，不一定是最终用户，也可能是消费这个服务的另外一个服务。

個人視其為 DevOps 文化的實踐。

5. 資料去中心化（Decentralized Data Management）

另外，尽管在分布式中，我们要想处理好一致性的问题也很困难，很多时候都没法使用传统的事务处理来保证不出现一致性问题。但是两害相权取其轻，一致性问题这些必要的代价是值得付出的。

以微服務來說有 Sagas Pattern 來解決跨微服務的交易，然而也增加了系統的複雜度，譬如開發團隊需要設計交易補償的處理流程。

6. 輕量級通訊機制（Smart Endpoints and Dumb Pipes）

如果服务需要上面的某一种功能或能力，那就应该在服务自己的 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）。

7. 容錯性設計（Design for Failure）

所以“断路器”这类设施，对实际生产环境的微服务来说，并不是可选的外围组件，而是一个必须的支撑点。

Circuit Breaker 對於微服務實踐已經是必要項目了嗎...。

8. 演進式設計（Evolutionary Design）

9. 基礎設施自動化（Infrastructure Automation）

雲端原生 (Cloud Native)

虽然 Spring Cloud 和 Kubernetes 的出发点不同，解决问题的方法和效果也不一样，但不容忽视的是，Kubernetes 的确提供了一条全新的、前途更加广阔的解题思路。

只好把 Vicent 哥的簡報再請出來了：
JCConf 2020 Vincent Huang - Google 簡報

云原生时代追求的目标，跟此前微服务时代中追求的目标相比，并没有什么本质的改变，它们都是通过一系列小型服务去构建大型系统。在服务架构演进的历史进程中，我更愿意把“云原生时代”称为“后微服务时代”。

若以服務的角度來看，的確追求的目標並無本質上的改變，然而 "雲端原生" 涉及許多不同領域，譬如解決了傳統 IT 操作模型的缺點，包括難以創建可擴展、容錯、自我修復的應用程式，以及低效的資源利用率等。單純用 "後微服務時代" 此一名詞難以含括其他領域的內容，簡單來說 "雲端原生" 與 "微服務" 雖有共同之處，但兩者的概念不同，可參考 CNCF 的中文定義：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

參考資料

註 1

相互之間交流的情況更糟一些。如果任務的每個部分必須分別和其他部分單獨協作，則工作量按照 n(n-1)/2 遞增。一對一交流的情況下，三個人的工作量是兩個人的三倍，四個人則是兩個人的六倍。而對於需要在三四個人之間召開會議、進行協商、一同解決的問題，情況會更加惡劣。所增加的用於溝通的工作量可能會完全抵消對原有任務分解所產生的作用。

—— 《人月神話：軟體專案管理之道》

註 2

Scrum Team 規模足夠小以保持靈活性，同時足夠大以便可以在 Sprint 內完成重要的工作，通常人數在 10 人以下。一般而言，我們發現越小的團隊溝通越好，生產力更高。如果 Scrum Teams 變得太大，他們應該考慮重新組織為多個有凝聚力的 Scrum Team，每個團隊還是專注在同一個產品，因此，他們應該有著相同的 Product Goal、Product Backlog 和 Product Owner。

—— 《Scrum Guides》

[outshaker]

作者按照自己的整理把整個架構的發展歷史分成六個時期

1. 原始分散式架構時期：這個時期有很多分散式系統的嘗試，催生了非常多之後仰賴的重要基礎(像是 DCE/RPC, DCE/DFS)。由於是發展初期很多技術或標準都還不足以完整解決問題，受到很多阻力，以致單體架構是當時最穩定的選擇

2. 單體架構時期：為了和微服務區隔而生的名詞，是最早出現的架構風格。
   特性：性能好，但隔離性差，如果單體內某個部件故障的話，很容易擴散到整個單體，沒辦法有效控管。

ps. 採用程序內呼叫，沒有跨程序間通信的問題

3. SOA 服務導向時期：為了區隔，開始有不同的解決方案 (煙囪式架構、插件式架構、事件驅動架構)。另外本時期的代表物為 SOAP 協議，企圖以非常全面的標準涵蓋所有狀況，但因為架構過於複雜，並沒有辦法被大家所接受，於是被時代的洪流沖散了

4. 微服務時期：2014 年的文章 "Microservices - a definition of this new architectural term" 揭開了序幕，至此和 SOA 劃開界線。總共有九個重要特性，影響了之後的架構發展

擺脫 SOA 束縛的架構，開始蓬勃發展

5. 後微服務時期：虛擬化、容器化技術成為推手，k8s 最終成為大家接收的事實標準 (docker 也不得不低頭)

6. 無服務時期：未知的新領域，大家還在持續探索。代表概念：BaaS (Backend as a Service), FaaS (Function as a Service)

---

剛接觸概念，技術名詞有點多，先抓住大概的發展脈絡

[Carisa-Li]

學習要點

軟體架構流變
服務架構隨硬體限制及軟體要求一同發展，不同情境各有適合的架構。
硬體性能有限⇒原始分布式
→硬體性能提升⇒單體
→軟體規模增加⇒無服務
$~~~~~~~~~~~~~~~~~~~~~~~~~~~~$⇒面向服務架構(SOA)
→SOA對一般應用情境過於複雜⇒微服務
→容器技術發展⇒後微服務(雲原生)

原始分布式

• 硬體性能極差時的探索，為後續奠立基礎。

單體

• 單一process
• 優點
  • 效率高
  • 小型系統的好選擇
• 缺點
  • 各功能間沒有隔離，單一功能的錯誤會影響整個系統的運行
  • 須停止整體服務才能更新
  • 需統一技術棧

面向服務架構(SOA)

• 拆分大型單體系統的嘗試，如煙囪式架構、微內核架構及事件驅動架構
• 試圖總結軟體開發的方法論
• 優點
  • 提供一套涵蓋軟體開發各方面的完整規範
• 缺點
  • 過於複雜，學習成本極高
  • 更適用於極大型系統，對多數情境而言過於龐雜

微服務

• https://martinfowler.com/articles/microservices.html
• 優點
  • 應用廣泛
  • 降低開發者成本
• 缺點
  • 無標準方案，對架構師有更高能力要求

後微服務

• 使用容器將分布式架構的問題交托出去
• 優點
  • 減少軟體需處理的問題
• 缺點
  • 目前仍在發展中

無服務

• 透過雲端系統創造出近乎沒有硬體限制的環境，因此無須採用分散式系統
• 優點
  • 效率高
  • 使用者無需考慮後端技術組件
• 缺點
  • 目前仍在發展中
  • 使用情境可能受限

想問的問題

暫無

[alxtz]

沒空能寫成 markdown, 先貼個筆記版 https://app.heptabase.com/w/9566bffb82a5be35984b539a17ba39d2e59860ca4787969066bcd8ccde6fb4d5?id=79aa75a6-7536-4c57-a561-a2d861ecb768 😿

---

問題集：

• 什麼是 snowflake server?
• self-replicating machine 是什麼
• hotswap update，除了 Java 的 OSGi，還有聽過哪些 solution 嗎？
• canary release 只聽過沒做過，通常會是怎樣的 setup
• Erlang/Elixir 也有 thread 容錯的概念，感覺跟鳳凰架構的理念很接近？（不過全篇都沒提到）
• JSR 這個東西，在 Java 圈子是很被推崇的 specification 嗎？
• 配置中心是什麼？
• 服務發現是什麼？
• Gateway 通常會有哪些職責？
• 服務治理是什麼？
• in process load balancer 和後來 cloud 版本的差別在哪？
• 聲明式 HTTP client 是什麼？
• (Netflix) Spring Cloud 有人用過嗎？還是主流？
• 專家帶領雜兵是否是軟體開發的必然？
• Istio 和 Linkerd 差別在哪？
• 白話文解釋 Unix 哲學？
• 是不是很多分散式系統經典論文，也是 1970-1980 開出來過的？
• DFS 和 HDFS 差別在哪裡？
• 什麼是 inter-process communication
• 想聽有沒有人用過 SOAP