微服務架構核心（一）- 什麼是微服務
微服務是目前網際網路公司最常用的架構，與傳統單體架構相比，微服務架構更加適應網際網路快速、靈活的特點，接下來的系列文章我會逐一介紹微服務架構的核心知識點。
第一篇我們先來了解什麼是微服務。
微服務的特點
微服務最經典的定義是Martinfowler老爺子在2014年的一篇文章中介紹的，原文如下：
the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms
, often an HTTP resource API.These services are built around business capabilities and independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
總結起來有六點：
- 一組小的服務
- 執行在獨立的程序中
- 使用輕量級通訊協議
- 基於業務能力構建
- 獨立部署
- 無集中式管理
為了能更好的理解這些特點，我們需要將單體架構拿出來與微服務架構進行比較。
假設有一個使用者資訊管理系統，包含了註冊、登入、資訊維護、授權四個核心功能。使用單體架構時，所有的功能會被放在一起，而使用微服務架構時，它們可以被拆分成四個獨立的服務。
下面我結合這張圖來一個一個說明微服務架構的六大特點。
一組小的服務
由於被拆分成四個獨立的服務，所以相對單體架構而言，微服務架構下的每個服務都更"小"了。
但要注意的是，這裡的"小"是相對的，沒有統一標準，例如程式碼少於N行，功能點少於M個。
在劃分微服務時，我們需要避免一味追求小而將微服務劃分得過細，因為這樣會提高系統維護成本。
執行在獨立的程序中
例如JAVA開發的單體架構系統，所有業務功能包含在一個WAR包裡，部署在相同的容器中，業務功能之間共享程序。
而微服務之間是獨立的，他們可以部署在一個容器裡，也可以分開部署，最重要的是它們之間不會共享程序。
這樣做有利於靈活的分配資源，各個服務之間也不會互相干擾。
使用輕量級通訊協議
在單體架構下，不同系統間的互動常常會使用重量級的協議，例如SOAP。
微服務由於拆分得更細，服務間呼叫更加頻繁，因此更傾向使用輕量級的協議，例如Http、RPC。
基於業務能力構建
劃分微服務的原則不是看它有多小，而是看單一的業務能力是否被劃分到一個服務中。
例如前面的使用者資訊管理系統，我們是按業務能力劃分了四個微服務，而不是按功能劃分出前端服務、接入服務、邏輯服務、資料庫服務。
獨立部署
在單體服務中，即使是一個小功能的改動，也需要重新發布整個系統。而在微服務架構下，只需要單獨部署有改動服務。
獨立部署的特性，使得微服務架構系統能夠以更快的速度迭代，而這也是網際網路軟體非常重要的一個特性。
無集中式管理
單體服務架構由於集中管理，所以使用的技術棧往往也是相同的。微服務架構則可以根據服務特性選擇不同的技術棧，例如註冊服務用 MYSQL + REDIS，資訊維護服務使用Oracle。
無集中式管理使得微服務架構系統的選擇性更多，可以根據需求選擇最優的技術方案。
總結
軟體架構體系經歷了單體 -> SOA -> 微服務 三個階段，總體的趨勢是劃分越來越細，每個服務承擔的職責越來越單一。
在前面介紹微服務的六個特點時，每個特點都能解決一些舊的問題，但是凡事都有兩面性，解決舊問題的同時也可能帶來一些新問題。
例如無集中式管理，增加了技術選擇性的同時，也增加了研發成本，因為研發人員需要掌握更多的技術知識。
除了我舉的例子之外，大家也可以思考一下，其它的特點都會帶來哪些新的問題？歡迎留言與我討論。