結構化面試提綱——容器&微服務

微服務

為什麼需要微服務

單體服務的問題
1.複雜性逐漸變高
比如有的專案有幾十萬行程式碼，各個模組之間區別比較模糊，邏輯比較混亂，程式碼越多複雜性越高，越難解決遇到的問題
2.技術債務逐漸上升
公司的人員流動是再正常不過的事情，有的員工在離職之前，疏於程式碼質量的自我管束，導致留下來很多坑，由於單體專案程式碼量龐大的驚人，留下的坑很難被發覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債務越來越多。
3.部署速度逐漸變慢
這個就很好理解了，單體架構模組非常多，程式碼量非常龐大，導致部署專案所花費的時間越來越多，曾經有的專案啟動就要一二十分鐘，這是多麼恐怖的事情啊，啟動幾次專案一天的時間就過去了，留給開發者開發的時間就非常少了。
4.阻礙技術創新
比如以前的某個專案使用struts2寫的，由於各個模組之間有著千絲萬縷的聯絡，程式碼量大，邏輯不夠清楚，如果現在想用spring mvc來重構這個專案將是非常困難的，付出的成本將非常大，所以更多的時候公司不得不硬著頭皮繼續使用老的struts架構，這就阻礙了技術的創新。
5.無法按需伸縮
比如說電影模組是CPU密集型的模組，而訂單模組是IO密集型的模組，假如我們要提升訂單模組的效能，比如加大記憶體、增加硬碟，但是由於所有的模組都在一個架構下，因此我們在擴充套件訂單模組的效能時不得不考慮其它模組的因素，因為我們不能因為擴充套件某個模組的效能而損害其它模組的效能，從而無法按需進行伸縮。
 

什麼樣的專案適合微服務

能不能做成微服務，取決於四個要素：
小：微服務體積小，2 pizza 團隊。
獨：能夠獨立的部署和執行。
輕：使用輕量級的通訊機制和架構。
鬆：為服務之間是鬆耦合的。

微服務的缺點

運維要求較高
對於單體架構來講，我們只需要維護好這一個專案就可以了，但是對於微服務架構來講，由於專案是由多個微服務構成的，每個模組出現問題都會造成整個專案執行出現異常，想要知道是哪個模組造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。

分散式的複雜性
對於單體架構來講，我們可以不使用分散式，但是對於微服務架構來說，分散式幾乎是必會用的技術，由於分散式本身的複雜性，導致微服務架構也變得複雜起來。

介面調整成本高
比如，使用者微服務是要被訂單微服務和電影微服務所呼叫的，一旦使用者微服務的介面發生大的變動，那麼所有依賴它的微服務都要做相應的調整，由於微服務可能非常多，那麼調整介面所造成的成本將會明顯提高。

重複勞動
對於單體架構來講，如果某段業務被多個模組所共同使用，我們便可以抽象成一個工具類，被所有模組直接呼叫，但是微服務卻無法這樣做，因為這個微服務的工具類是不能被其它微服務所直接呼叫的，從而我們便不得不在每個微服務上都建這麼一個工具類，從而導致程式碼的重複。
 

微服務開發框架有哪些？

Spring Cloud：http://projects.spring.io/spring-cloud（現在非常流行的微服務架構）
Dubbo：http：//dubbo.io
Dropwizard：http://www.dropwizard.io（關注單個微服務的開發）
Consul、etcd&etc.（微服務的模組）

微服務負載均衡方案？

微服務服務發現方案？

微服務限流熔斷方案？

Docker

Kubernetes

K8S的架構和核心元件

Kubernetes主要元件有API Server、Controller Manager、Scheduler、kubelet、kube-proxy
etcd儲存了整個叢集的狀態；
apiserver提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制；
controller manager負責維護叢集的狀態，比如故障檢測、自動擴充套件、滾動更新等；
scheduler負責資源的排程，按照預定的排程策略將Pod排程到相應的機器上；
kubelet負責維護容器的生命週期，同時也負責Volume（CVI） 和網路（CNI） 的管理；
Container runtime負責映象管理以及Pod和容器的真正執行（CRI） ；
kube-proxy負責為Service提供cluster內部的服務發現和負載均衡