Day 13 ~ 17 主要講資料記憶體如何存成檔案或 binary 的格式，也就是 encoding 和 decoding，到了最後一部份，要講講資料有哪幾種方式能讓它從某個 process 流到另一個 process (data flow)，是誰 encoding 或 decoding 資料的？先來列一下常見的幾種方式：

• 通過資料庫 (database)
• 通過服務呼叫 (service call)
• 通過非同步訊息傳遞 (asynchronous message passing)

通過資料庫的 dataflow

在資料庫中，有個 process 可能負責寫入資料 (encoding)，另個 process 可能負責讀取資料 (decoding)，也有可能是在同一個 process 作業，所以讀取者 (reader) 可以很輕易的用最後版本的 schema 來讀取資料，這裡可以想像成 寄一封訊息給未來的你，所以向後兼容在這裡是必要的，否則未來的你不認識你在寫什麼東西，

至於向前兼容呢？通常資料庫同時會有多個 process 在存取，某個 process 可能來自不同的應用程式或服務，而應用程式會改變，這就代表有些 process 是被取新版本的程式存取，有些 process 是被舊版本的程式存取，也就是會有舊版本的程式會讀取到新版本程式寫的資料，所以向前兼容也是必要。

另外還有一個要留意的點是，在 應用程式這個等級下 (application level) ，舊程式可能會回寫整筆資料，導致新程式寫的資料缺失，如下圖說明，理想狀態是新程式寫的新欄位，舊程式在回寫資料時不會動到新欄位，解決這個問題不難，但你要知道你的程式可能會發生這種情況。

通過服務呼叫的 Data Flow: Rest and RPC

當你需要讓資料在網路上傳遞時，通常會把角色分為 client 和 server ，server 揭露 API，而 client 向這些 API 發 request，這些 server 也可稱為 service (服務) ；client 有很多種，瀏覽器、原生 app、AJAX、server 都可視為 client，server 做為 client 端可以是向資料庫發送需求，或者向另一個 service 發送 request，這種建置系統的方式也被稱 microservice architecture (微服務架構) 。

微服務架構的關鍵想法讓整個應用系統更易於改變和維運，因為每個 service 都能獨立給一個團隊負責，而每個 service 都能自己部署和更有進化性。

Web services

當你是用 HTTP 當做 service 的協定，我們稱為 web services，web 不只能讓網站使用，舉例來說：

1. 在 user 的裝置裡執行的 client 應用程式 (原生 app 或 AJAX)，透過 HTTP 發 request 給 services。
2. 組織內部的 microservice。
3. 不同組織間的 service 溝通，通常用在資料交換或者後端程式 (信用卡授權 service、OAuth service 等等)

這裡有 2 種流行的方法來做 web services，REST 和 SOAP，

REST 不是一個協定，而是一個基於 HTTP 原則的設計哲學，它強調簡單的資料格式，使用 URLs 來識別資源和使用 HTTP 有的功能來做 cache 控制、授權和內容類型協商 (GET, POST, UPDATE etc..)， REST 原則來設計的 API 稱為 RESTful API。

SOAP 是一個以 XML-based 協定來產生網路用的 API request，雖然它是用在 HTTP 上，但它的目標是獨立於 HTTP (不用 HTTP 有的功能)，然後用一堆協定、功能來讓 web services 變的更複雜。

RPC (remote procedure calls)

RPC 一個最大的賣點是讓你在程式中當 local function 呼叫的方式來使用，但這本質上就是有缺陷的，因為最終還是透過網路來 call service，古老的 RPC 有 Enterprise JavaBeans (EJB)、 Java 用的 Remote Method Invocation (RMI)、Microsoft 用的 The Distributed Component Object Model (DCOM) 和很複雜的 The Common Object Request Broker Architecture (CORBA) ，這些都很難做到向前與向後兼容。

所幸現在我們有許多好用的新選擇，這些 RPC 框架知道遠端 request 跟 local function 呼叫是不一樣的，它們會用我們前幾天講的那些 encoding 方式，例如 Thrift 和 Avro 都支援 RPC、gRPC 是使用 Protocl Buffers、Finagle 也用 Thrift、Rest.li 透過 HTTP 使用 JSON。

這些框架提供 service discovery (服務發現) 來讓 client 知道哪些 IP 跟 PORT 是可呼叫的；雖然 RPC + binary encoding 的效能會比 JSON + REST 好，但 RESTful API 有個很大的優勢是比較好做實驗和 debug，但想怎麼用還是看個人啦！

我們公司就把內部所有 microservices 間的溝通都改成 gRPC。

明天待續 通過非同步訊息傳遞 (asynchronous message passing) 和結論。