At high level
1. external communication （North-South traffic) - 不在同一個K8s cluster之中的service之間的通訊，使用K8s 的exgress controller
2. internal communication (East-West traffic) - 在同一個K8s cluster之中的service之間的通訊，使用K8s 的ingress controller
Protocols
HTTP是最常使用但不見得是最好效能者，優化效能的話，可以透過proxy轉換protocol:
1. Websockets - 適合雙向長時間，透過單一TCP socket建立全雙工低overhead的連線。首先透過HTTP request要求建立WebSocket連線。低延遲也是一個特點。
2. HTTP/2 - binary data protocol，特別適合低延遲高效率的串流通訊。
3. gRPC - 建立在HTTP/2上的lightweight transport protocol，在微服務社群中逐漸受到歡迎，提供包括身份驗證 / 雙向streaming / flow control / blocking bindings / cancellation & timeouts。
Messaging Protocols
cloud native天生使用event-driven / message-based approach，所以我們來看一下兩個主要的protocols:
1. MQTT (Message Queue Telemetry Transport)
通常用在IoT / 機器間 的binary protocol，例如在low-bandwidth環境下的sensor跟gateway的溝通。非常lightweight的publisher/subscriber的scheme。
2. AMQP (Advanced Message Queuing Protocol)
MQTT的rich feature set版本，所以相對不是那麼lightweight跟快速，但是也被許多vendor驗證過是很可靠的，所以在不同vendor的service間溝通可以使用AMQP。
Serialization Considerations
data serialization也是影響效能的一個可能。
1. JSON - 最常使用，但是有較大的memory footprint，所以也會花費計算在serialization / deserialization較大。JSON serializer的選擇就很關乎效能。
2. Protobuf - 由於是binary format，所以效能較佳，幾乎所有現代語言都有相對應的generator。message schema會預先定義在某個proto file，所以每個service預先會有此proto file才知道如何serialize/deserialize data。
Idempotency (冪等性)
service對任意的request每次都能產出一樣結果的話，稱為idempotency，一個可能發生不idempotency的場景是，某個API因為網路不穩而重新送了兩次request，造成service端重複process了同樣的data兩次，若是不符合idempotency的API有可能會造成錯誤。常見的解決方法是加上unique request ID，所以已經process過的ID就不會再process，避免了non-idempotency的可能，也稱為de-duping。
Request/Response
synchronous pattern就沒什麼好說的，一來一往等待：
asynchronous pattern的話，就要確保request方知道目前的response是對哪一個request的回應，這可以用message queue + correlation id (CID) 來達成:
publisher/subscriber
cloud native app中最常見的async communication pattern，多個subscriber訂閱某個topic，當publisher push message時，中間角色的broker對所有subscriber廣播出去。
- pub / sub 是完全獨立解耦合的
- event driven design
注意事項
1. async communication不保證接收到訊息的順序，所以需要注意idempotency issue
2. 如果care接收到訊息的順序，可以善用messaging system的內建ordering functionality或是使用priority queue pattern
要選擇Pub/Sub or Request/Response?
case by case依照application需求而定，例如以下為同一個cloud native app採用兩種approach：
data flow是 S1收到client async request後，處理完後又對S2 / S3也發出request。S3處理完後，向S4 / S5發出request。
Request/Response - S3要等待S4/S5處理完才能respond to S1，有可能因為fail而timeout，但是client端可能要很久之後才發現fail，而且必須處理idempotency，免得客戶多發了很多次request造成資料異常。換言之，request/response對每個參與的service來說是高度耦合的。
Pub/Sub - 較低耦合度，透過中間pub/sub系統例如 Redis/RabbitMQ/Apache Kafka。
Synchronous vs Asynchronous
所有的service instance基本上就是一個process，彼此間的溝通就是IPC (interprocess communication)機制，用synchronous communication有主要三個問題：
1. scale up時會因為等待response而被block住，容易產生資源瓶頸
2. response延遲時間是喔死有節點的延遲加總，所以其中一個慢，會讓client端的整體response latency高。
3. 錯誤累積，這類似2. 的問題。
所以cloud native app基本上是採用asynchronous communication。
