微服務的基本概念
所謂微服務，最直白的字面理解，就是小規模的服務。其實，微服務是一種架構設計理念，它是對SOA的一種改進。它把原來大的集成服務拆分成若干個獨立的小的服務。服務和服務之間通過調度和協作完成集成服務所完成的業務。在Java中，使用SpringCloud完成整個微服務架構。
微服務的優缺點
優點：
- 利於整個服務的橫向擴展。可以更加細粒度的擴展某些微服務，資源可以得到最大化的利用；
- 由於微服務間的解耦，可以只改動或升級某些微服務，升級維護成本大大降低；
- 微服務的各個開發團隊，可以更加專注於自身領域的業務，提高了開發效率；
缺點：
- 需要解決數據庫分佈式事務難題，增加了開發難度
- 需要有統一的網關收口，增加的開發量
- 服務間的調用產生了網絡開銷，降低了程序效率
為什麼要用微服務
關於這個問題，小編只能說，好多公司都沒搞清楚這個原因。更多的公司，進行微服務改造，是因為公司的CTO為了秀技術，又或者是拿公司資源學習做實驗。
很多公司老項目，是springmvc框架開發，基於SOA開發設計的也很好。應用程序運行也很穩定，即便業務量上來了，通過簡單的集群拓展就可以解決了。
那麼為什麼要用微服務？因為不用的話，公司的CTO會覺得自己很low，也怕鎮不住小弟們。而公司空降過來的CTO，必須要對老程序進行一定規模的改造（否則，老闆請你來是喝茶的嗎？），而遇上這個微服務的風口，剛好是一展身手的機會，豈能容許錯過？並且還會加上如何應對應用大併發，甚至會加上大數據Spark，搜索引擎ES等，反正能秀的一定要秀出來。
為了微服務而微服務
在改造過程中，有的CTO還是蠻盡心盡責的。但有的改造就不盡人意了，或許是技術能力問題，但更多的是做事態度問題。於是，在改造過程中，只是照葫蘆畫瓢，改了一個形似而已。
就說一個最簡單，微服務的最基本要求，各個服務之間的數據存儲是獨立的。這也是為什麼微服務會有分佈式事務難題的原因。但是，讀者們可以看看自己公司的應用，或者問問朋友公司的應用，有多少，從頭到尾就一個mysql實例，在這個實例中就只有一個數據庫。往往是一個工程，建立了二十幾個所謂的微服務模塊，然後，一個mysql實例（還特麼是單點），mongo或許還能搞一個副本集集群，但redis又弄成了單點。最搞笑的是，每個微服務還啟動了兩個實例，美其名曰“集群”，但是，網關又弄成一個單點了。