在去年的時候就提到了，在接下來的一年，測試必然會接觸到微服務的測試，而在微服務測試的層次，首先需要了解的是微服務到底是什麼，它的通信機制又是什麼，對測試的挑戰又是什麼，面對微服務，我們應該以什麼樣的思路和态度來面對這些了？在本篇文章對微服務做一個簡單的介紹。在後面的文章中會逐漸的介紹裡面的細節知識。
首先什麼是微服務，微服務是一種架構模式，也是一種思想，它倡導将單一應用程式劃分成一組小的服務，服務之間互相協調，互相配合，為使用者提供最終價值。每個服務運作在其獨立的程序中，服務與服務間采用輕量級的通信進制互相溝通。(基于HTTP協定是RESTFUL API)。每個服務圍繞具體的業務建構，并且能夠獨立部署到生産環境中。在這裡可以擷取到這麼幾個關鍵資訊，第一是微服務它采用輕量級的通信方式，第二是它将一個單一的應用劃分成N個小型的服務，而服務之間根據業務互相協調和配合，第三是每個微服務它是一個獨立的程序，第四是微服務與資料庫之間不是絕對的，也就是說，不一定說每個微服務都必須有自己的資料庫，而且很有可能是多個微服務使用了一個資料庫執行個體，也有可能是一個微服務使用了一個資料庫，這具體得根據業務場景。
在微服務的通信機制是采用輕量級的通信方式，也就是基于HTTP協定的RESTFUL API,HTTP協定它是應用層的協定，是以不需要太多的去關注底層網絡傳輸層的事情。在微服務通信機制中，分為兩類，一類是同步通信的機制，另外一類是一步通信。同步通信比較好了解，也就是說用戶端發送請求到服務端的過程，在這個過程中，用戶端與服務端之間是有互相依賴的，用戶端發送請求後，服務端必須得回應用戶端的請求，而作為服務端還是用戶端，它能夠感覺到對方的存在并且等待對應的回應，但是可能會由于網絡因素等其他的異常情況，比如逾時，導緻用戶端發送請求到伺服器端後，需要遲遲的等待或者等待逾時，因為這種方式有缺陷也有好處。而異步通信方式中，用戶端與服務端之間沒有太多的依賴性，簡單的說就是用戶端發送請求後，它不需要刻意等待被請求服務的回應，而對方也不知道用戶端的存在，是以這樣的一個通信方式中，這種方式使用輕量級消息傳遞代理。作為A和B兩個服務，A服務生成一個消息後發送給消息代理，而訂閱主題的B服務将提供屬于該主題的所有服務。A和B服務之間根本不需要互相了解對方的存在，他們隻知道某中類型的消息存在即可。
作為微服務而言，會有很多的優點，當然缺點也是存在，這也是為什麼在談論微服務或者devops的時候不得不談論康威定律，關于該話題到後面具體讨論。在這裡隻是簡單的看下微服務的優點，它的優點主要是易于維護，技術選型比較自由，不會捆綁在一個語言上面，易于擴充，獨立部署，更好的組織支援群組織效率。
微服務給測試的挑戰在我個人了解，主要是這麼幾點，第一點是技術的擴充，因為在面對微服務測試的時候，不得不了解通信的方式，微服務之間的各種請求和請求順序以及邏輯；第二是對過去認知的一種颠覆，我們一直在金字塔的模式中來進行分層，但是在微服務的架構模式下，金字塔的測試模式依然會被使用，但是會增加新的層次，比如契約測試，元件測試，端到端的測試；第三，它讓我們不得不去思考它帶來的好處和帶來的壞處，關于這點，後面具體說康威定律；第四，平台化的思路與服務，微服務的趨勢是paas，也就是平台即服務，Platform As A Service；第五是如何在微服務架構的模式下，更快，怎麼樣可以打造高效的組織效率和研發效率，和符合要求的産品品質。對于測試而言，基于微服務的架構下，會越來越複雜，也會面臨剛才說的很對的挑戰，這種挑戰一方面是技術方面，另外一方面是思路方面。