微服務架構設計 (一): 核心概念

微服務設計是架構設計。

是以, 微服務設計不應是一個講求标準答案, 簡單粗暴的設計過程。而應該是一個考量各方因素下的一個決策的過程。

是以, 在探讨微服務設計前, 我們先來探讨下, 所謂的微服務具體應包含哪些核心的概念?

微服務與微服務間分布式調用最主要的概念便是: protocol-aware heterogeneous interoperability; 各微服務可各自擁有自身的 platform (java,c＃, scala…等等), 但, 各微服務間卻隻能藉由單一共同的協定 (protocol); 如: rest; 進行分布式的調用。

微服務架構的産品或許會有數百甚至數千個微服務所構成。是以, 部署微服務時, 便很難經由手工來完成, 而必須相當程度的依賴自動化的 devops 工具。

service registry and discovery

deployment

monitoring

zookeeper

doozer

etcd

smartstack

eureka

nsq

serf

spotify

dns

skydns

consul

cloud foundry

gradle

docker

docker hub

docker machine

kitematic

docker compose

docker swarm

aws

jenkins

continuum

hudson

artifactory

terraform

grunt

openshift

sonarcube

logstash

new relic

graphite

mesosphere / dcos

winston

hystrix

微服務是以服務元件, 而不是以類或子產品的方式展現; 每個服務元件會包含一個或多個類或元件。

<b>微服務共分為兩大類:</b>

a. infrastructure services: 主要是為産品中其他的微服務提供服務; 被産品中其他的微服務直接的調用。

如: login service 便是一infrastructure services 的例子; 主要是為産品中其他的微服務提供産品登入的服務。

是以, infrastructure services 對産品外部的使用者界面、系統、裝置都是不可見的, 也就是說, 産品外部的使用者界面、系統、裝置是無法經由 api layer 來找到 infrastructure services 的。

<b>b. functional services:</b> 主要是為産品外部的使用者界面、系統、裝置提供某一端到端業務場景的服務。

是以, 相對于 infrastructure services, functional services 對産品外部的使用者界面、系統、裝置而言, 都是可見的。也就是說, 産品外部的使用者界面、系統、裝置是經由 api layer 來找到 functional services 的。

微服務的邊界上下文包含:

<b>a. </b>某一端到端業務場景 (功能) 。

<b>b.</b> 資料 (資料庫) 。

微服務的邊界上下文, 使得每一個微服務擁有各自的某一端到端業務場景 (功能)與資料 (資料庫) 。

更重要的是: 當微服務x需調用微服務y, 則微服務x 與微服務y的邊界上下文, 将可避免或降低發生, 當微服務y 運作失敗時, 會影響到微服務 x。

是以, 微服務的邊界上下文提供了一個很重要的微服務概念：微服務應能獨立各自的開發、測試, 并且當釋出、部署後, 亦不緻影響到其他微服務的功能或運作。

因為, 微服務間共享任何的事物, 将會造成微服務間的依賴。

是以, 微服務間應避免共享任何的事物; 如:繼承結構下的抽象接口, 服務, 子產品, utility, 類, 資料 (資料庫)…等等。

api layer 主要是在微服務與微服務外部的使用者界面、系統或裝置之間建構:

<b>a. endpoint proxy:</b> 隐藏各微服務的 endpoint。

當某個新增的場景在某個新的微服務上開發完後, 這個新的微服務便會有了新的 endpoint。 而api layer 便可将此微服務外部的使用者界面、系統或裝置導向此新的微服務上的 endpoint。使得微服務外部的使用者界面、系統或裝置可在不需要有任何修改的情況下, 便可以使用此新的微服務。而當微服務外部的使用者界面、系統或裝置發現此新的微服務不适用時, api layer 便可将微服務外部的使用者界面、系統或裝置導向舊的微服務上的 endpoint, 而使得新的微服務, 對微服務外部的使用者界面、系統或裝置而言, 變得不可見。

<b>b. load balancer</b>: 多節點間的負載均衡。

當某個微服務開發完後, 便應避免不要再在此微服務上, 不斷的加新的場景或功能; 新的場景或功能應該是屬于另一個新的微服務。

<b>本文作者:</b>

方俊賢 (ken fang), 曾任職于 iji, rational, telelogic, borland◦ 有将近二十年在半導體, 電信産業與軍事研究機關, 從事軟體工程與精益靈活開發相關咨詢服務的經驗。 主要專長是精益靈活開發, 有價值的産品需求挖掘, 使用者行為場景分析, 動态注入架構設計, roa, 既有軟體架構優化, 探索式測試, 靈活測試與持續內建。