Python 的 Coroutine 發展已經逐漸穩定成熟，已經成為了提升 Python 程式效能的優秀解決方案之一，在之前簡單介紹 Coroutine 和 await/async 時，我們在範例 code 中一直有用到一個 Python buildin 模組
asyncio，它提供了一套完整的工具和接口，用於建立非同步應用程式，其核心是 Event-Loop，會追蹤所有註冊的任務，並根據任務的狀態調度它們的執行。 故接著來了解 Event-Loop 和其工作的執行單位 Task 吧 !
之前有介紹了 Asynchronous ，而 Python 的 Coroutine 是實現 Asynchronous 的一種設計方式，且 Python 目前已經有非常直觀簡單的語法糖來定義 Asynchronous Code，使得程式寫起來就像普通的 「 Sequential Processing 順序執行 」任務那樣，但同時卻也可以對目標函數標註做「等待」的動作，並在「等待」期間可以先去做其他任務，達成非同步的功效，提高程式的並發性，而其重要的關鍵字就是 :
async: 用來宣告 function 能夠有異步的功能成為 Coroutine functionawait: 用來標記 Coroutine 切換暫停和繼續的位置而這兩個關鍵字是在
Python3.5引入且在Python3.7成為保留關鍵字。它們在著名的 FastAPI 框架下的 path operation function 下也經常使用，接下來就簡單介紹一下吧。
前面基本介紹了 Process 、 Thread，而在現實世界中 Process 、 Thread 的任務是更加複雜的，都會是需要「多執行緒(Multithreading)」和「多進程(Multiprocessing)」來協調達成的，再來是要如何更高效更多工的處理多個不同的工作，變成是經常需要思考的問題，這時 :
- 非同步（Asynchronous） : 執行 Non-blocking 操作，允許程式在等待某些操作完成時可執行其他任務，之後可再回頭處理之前等待操作剩下的部分
- 併發（Concurrency） : 是系統能夠在一段時間內處理多個任務，這些任務可能交錯執行，不一定要同時發生
兩個關鍵字會經常一起出現，因為 Concurrency + Asynchronous 是許多高效能應用的關鍵，接下來就簡單談一下吧！另外可以稍微注意一下其他相關名詞的中文英文對照。
電腦運行時任務的的單元是什麼呢？ 這個涉及了「程式(Program)」、「進程(Process)」、「線程(Thread)」的概念，是面試時經常會被問到的題目，首先默念默背一下教科書上 Process 和 Thread 的簡單定義：
- Process： 資源分配的最小單位
- Thread： CPU 執行的最小單位
在實際生活中如點開一個聊天應用程式，這就是將 Program 活化成 Process 的例子，因此我們可以在電腦的資源管理器 Monitor 中看到 PID (Process ID) ; 再繼續以聊天室 Process 為例，我們可以同時「接受對方傳來的訊息」以及「發送自己的訊息給對方」，這就是同個 Process 中不同 Thread 的功勞。
GCP 雲端資源的權限管理服務是 IAM，其全稱為 Identity and Access Management，可讓管理員(Administrator)去授權(authorize)一個 Identity，使它可以操作特定的 Resources。對應到其他的雲端服務是 :
- Amazon Web Services (AWS) : AWS Identity and Access Managemen
- Microsoft Azure : Microsoft Entra ID (舊稱 Azure Active Directory)
簡單從英文上來說 IAM 是做什麼的 : 「manage who can do what on which resources」，此概念會貫穿整個 IAM 的使用，用於保護 GCP 資源，提供了非常細粒度的控制，可根據具體需求定制安全性策略。
Pub/Sub 是 Google 推出的 Message Service ，作為中介層(Middleware) 可讓系統解耦，解耦的兩系統透過 Publish-Subscribe 的模式來 「異步 asynchronous」 收發消息，實現高可靠(highly reliable) 和高可擴展(scalable)的服務。 簡單以 Event-Driven 消息傳遞設計為主體概念的話，對應到其他的雲端服務是 :
- Amazon Web Services (AWS) : SQS + SNS
- Microsoft Azure : Azure Service Bus Messaging
Pub/Sub 也簡化了許多 Message Service Infra 的管理如 Broker、Exchange、Queue 等這些底層架構組件並不會直接被使用者接觸，而是 GCP 完全代管且提供 Pub/Sub service level agreement (SLA)，developer 僅需要瞭解 Message、Topic、Publisher、Subscription、Subscriber 這些接近應用程式端的 Components，算是降低門檻達到快速使用的目的。
在前面幾個章節有介紹了 GCP 常見的 Storage Service ，有提供了各種高可靠且高可擴展存儲服務產品，雲端化直觀的提供了「減輕管理服務基礎架構」的負擔，特別是是硬體角度的管理。從比較 High-Level 角度來討論的話，雲存儲的服務類型分成
- Block Storage : Compute-engine 的 Persistent Disk
- Object Storage : Cloud Storage
- File Storage : Filestore
- SQL : Cloud SQL、Cloud Spanner
- NoSQL : Firestore、Bigtable、Memorystore
- Data Warehouse : Bigquery
在現今的雲端計算時代，儲存和管理大量資料變得更加重要，以上這幾種儲存服務需根據業務來選擇，因為這也會決定到訪問和管理組資料的難易程度，故以下對其做一些廣義的整理和筆記來幫助和選擇適合的儲存服務。
BigQuery 是 Google 提供的一個無伺服器資料倉儲 (Serverless Data Warehouse)，其支持 ANSI SQL 來搜尋資料，所以只要會 SQL 語法就可以立即開始使用，且可高效率分析 TB、PB 等級的資料，故 Bigquery 也是企業級雲端大數據資料分析平台。對應到其他的雲端服務是 :
- Amazon Web Services (AWS) : Athena、Redshift Spectrum、Redshift
- Microsoft Azure : Azure Synapse Analytics
Google 在非常早期的時候，就有類似 BigQuery 其的服務就存在了，是自 2006 年以來一直在內部使用的 Dremel，後來隨著 GCP 雲端平台的產生，並於 2011 年以 BigQuery 為名被正式推出。目前是 GCP 分析資料的主力產品， Google 自家產品如搜尋引擎、 Gmail 等服務背後，其資料處理與分析的核心技術也和 Bigquery 息息相關。
Memorystore 是 GCP 提供的完全託管 In-Memory Database 服務，可以輕鬆地在 GCP 上建立 Redis 和 Memcached 等著名的開源 Caching-Engines，專門提供毫秒級的低延遲資料存取/寫入，並減輕管理 Database 的部署 deployment、Replica、容錯移轉等等維運事項。對應其他的雲端服務是 :
- Amazon Web Services (AWS) : Amazon ElastiCache
- Microsoft Azure : Azure Cache
Memorystore 也是屬於 NoSQL，由於常用於快取情境故也會被稱呼為快取資料庫。目前看起來主流是使用 Redis，故建議在大部份的使用場景上，優先考慮使用 Redis。
Cloud Spanner 是 Google 開發的一個完全託管關係型資料庫，屬於企業級 PaaS 解決方案，具有全球同步、全域事務、強一致性、可擴展、分散式和 Replica/Failover 功能，可保證
99.999%可用性 SLA，使用者不需要多花心思在底層的基礎建設與管理。對應其他的雲端服務是 :
- Amazon Web Services (AWS) : Amazon Aurora
- Microsoft Azure : Azure SQL Database (SQL Server base)
Cloud Spanner 於
2012年開始為 Google 內部的重量級產品如 Youtube、Gmail、Google PlayStore 等等提供服務，取代了 Google 的自定義 MySQL 且號稱是盡量滿足 CAP 理論限制。2020Q1 統計每月約 1 億活躍使用者，每天有高達 1800 萬次外送記錄的 Uber，是使用 CLOUD SPANNER 成功案例。
