在寫架構的時候，就要想著，哪些功能是要以後可能要單獨部署的，雖然一開始寫的時候可以寫在一個解決方案裡，但那些請求的dto，和返回的檢視，業務依賴，能隨時獨立出去，完全不需要做任何操作，即使是資料夾複製移動都不需要，就能夠把該功能獨立成一個解決方案，做到獨立部署，然後透過遠端介面的方法呼叫處理獨立部署的業務；我認為這是微服務架構的最主要的作用。當業務多起來了，資料量大了，用微服務架構開發的應用，可以很快的把一個資料庫拆分成不同的資料庫，分伺服器部署，實現突破業務瓶頸；
其實我理解的微服務，就是把以前一個介面一個資料庫裡實現的邏輯，改變為透過一級或多級遠端呼叫去不同的伺服器和資料庫獲取資料，然後完成整個邏輯。這也算是分散式開發技術了，每次業務要保證在多級遠端呼叫過程中，資料的一致性，在儲存資料時，因為是分不同資料庫，不同伺服器儲存資料，有可能一個請求，要儲存或更新a、b、c三個不同地區裡不同伺服器的資料庫。就需要保證分散式資料儲存的acid：原子性、一致性、隔離性、永續性。
雖然，我在工作中，沒有太深入的接觸這方面的內容，但感覺得出，這些微服務，分散式技術，只是有這個需求才產生的，以前分散式不火，因為那時候一個資料庫curd就沒有超過效能瓶頸，而且網路條件也不太發達，使用網路的使用者也不多，現在，網路發達了，網民多了，產生的資料就變多了，對於一些企業，一個資料庫就有效能瓶頸了，所以就需要分庫開發，感覺分庫就和微服務是十分匹配的。那些資料多的企業就需要使用這種技術，而那些業務量小的企業，而且資料量一直很穩定，或者並不是直接靠網路資料生存的企業，比如一些把計算機程式設計技術作為輔助的，其核心是生產製造一些電子產品、工業產品、應用食品的企業，這些企業中的中小型個體或集團其實可能不需要用到微服務架構吧，就不必花大功夫去想處理什麼介面冪等、分散式事務這些分散式架構的缺點吧。
我感覺吧，任何事物，都是要隨其自然，技術的更新迭代大多也是在於有現實的痛點或瓶頸的倒逼；不斷解決這些瓶頸問題，就是在創新，就是在進步；人也一樣，有的人有瓶頸了就成為他們的上限了，有的人就能解決瓶頸，實現進步。