什么是微服務
微服務架構中最理想的模型是每個服務可以單獨執行并且具有自己的業務邏輯、數據庫、中間件、機器資源，并且隨著業務邏輯的改變，相應功能的開發和配置成本低。一個電子商務系統分為用戶管理、訂單管理、庫存管理、支付管理等微服務模塊。業務擴展后，需要追加另一個優惠券管理模塊，更加方便地追加。直接開發這個模塊的功能，向微服務網關添加路徑。
然而，問題是如何管理來自微服務的分裂的多個微服務。作為優化容器，可能需要最低水平的硬件資源。之后進行完全自動化系統的開發、測試、發布和維護。這些基本能力的建設和維護成本也很高。因此，在技術改革中，需要考慮到自己的業務進行快速反復嗎？基礎力的建設怎么樣？不要把馬車放在馬的前面。
微量服務困難狀況的分布狀況
該消息必須使用微服務技術架構并使用分布式配置架構。分布式架構可以將單機開展的業務分成多臺展開，根據業務狀況，具有無限的靈活性，實現高性能、高利用性、高合并性。
但是，使用分散裝置的情況下，也存在數據的整合性等很多問題。提供這個服務的服務，因為不同用戶的數據版本不能不同，所以整體上都很混亂。因此，在使用分布式服務模式之后，分布式事務保證了工作的原子性，在多人以相同服務工作時需要分布式鎖的原子性。這些是使用分布式架構的額外費用。我們必須享受并支付這些費用。技術改革需要考慮自己的業務是否需要高功能？可以負擔分布式的費用嗎？不要因為一點小事就出大事故。
為微型服務困難04服務通信
在服務不拆分微服務之前，模塊與模塊之間的通信通過內部呼叫來實現，并且不存在網絡延遲。但是，如果服務分類為微服務，模塊就會變成微服務。微服務與微服務之間的網絡通信是外部呼叫的實現。如果網絡通信有問題的話，整體的服務質量就會降低。因此，在技術改革中也需要考慮非技術成本等。
微服務確實不錯。例如，阿里、京東、美團、滴滴等大型互聯網公司將自己的業務系統升級為微服務體系。公司整體的在線是微服務系統。另外，我們可以參考大工廠的經驗，但在實際開始之前，必須結合自己的經營狀況和資源狀況來測定它們是否真正適合。
