什麼是微服務架構，如何做服務拆分？

講微服務之前，我們依照慣例，先講講單體架構

經典的單體應用架構

單體架構概述：

把所有的業務模塊都堆砌在一個系統中，然後把系統打成一個war包或者jar包運行在應用伺服器中

單體架構的優點：

• 架構單一，容易維護
• 開發、測試、部署都比較便捷

單體架構的缺點：

• 複雜度高
• 部署慢，而且體積很大，不利於發布
• 佔用伺服器資源過大
• 阻礙新的技術創新

微服務概述

馬丁.福勒微服務架構博文譯文https://martinfowler.com/

2014 年一位名為 馬丁.福勒 的工程師提出微服務架構設計理念，我們看看大致翻譯學習一下它的博文https://martinfowler.com/articles/microservices.htmla definition of this new architectural term

「Microservices」 - yet another new term on the crowded streets of software architecture. Although our natural inclination is to pass such things by with a contemptuous glance, this bit of terminology describes a style of software systems that we are finding more and more appealing. We』ve seen many projects use this style in the last few years, and results so far have been positive, so much so that for many of our colleagues this is becoming the default style for building enterprise applications. Sadly, however, there’s not much information that outlines what the microservice style is and how to do it.

In short, the microservice architectural style [1] 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.

譯文：

微服務架構風格是一種將一個單一應用程式開發為一組小型服務的方法，每個服務運行在自己的進程中，服務間通信採用輕量級通信機制 通常用http資源的api來實現。這些服務圍繞業務能力構建並且可通過全自動部署機制獨立部署，這些服務公用一個最小型的集中式的管理，服務可用不同的語言開發，使用不同的數據存儲技術

典型的打車軟體微服務架構圖

微服務架構的特徵：

• 每個微服務可獨立運行在自己的進程裡
• 一系列獨立運行的微服務共同構建起整個系統
• 每個微服務可用獨立的開發，在開發過程中只關注一個業務模塊的特定功能，比如支付服務，訂單管理，用戶管理等等
• 可使用不同的語言與數據存儲技術（契合項目情況和團隊實力）
• 微伺服器直接通過輕量的通信機制進行通信，比如：Rest API進行調用
• 全自動的部署機制

微服務架構的優點：

• 單個服務更易於開發、維護
• 單個服務啟動比較快，部署也快，消耗的伺服器資源更少
• 技術棧不受限制

微服務架構的缺點：

• 運維要求高
• 分布式服務固有的複雜度

什麼樣子的場景適合用微服務

• 大型項目
• 有快速迭代的要求
• 訪問壓力過大的網站

什麼樣子的網站不適合微服務

• 業務穩定
• 迭代周期長

微服務拆分的方法論

• DDD領域驅動設計
• 面向對象驅動設計
• 按照職責劃分（就是我們說的：訂單模塊、搜索模塊等）通用性劃分 （把一些通用功能做成微服務：比如用戶中心，支付中心、消息中心等。比如阿里流行的：大中臺和小中臺的概念，一個中臺其實是由：若干個微服務組成的）

微服務的設計的合理性

• 滿足業務的後續的擴展和延展
• 滿足團隊的成員的職業和技術的發展
• 可以穩步的迭代和更新你的業務
• 可以持續的更新或者調整你的技術架構，以及完全的可靠和抽離

建議：在實際的開發和生產中，如果你的項目屬於早期或者剛開始，通過分析以後模塊和業務並不複雜，其實不建議用微服務去架構，使用微服務一定要按照公司現有的資源，人員的實際情況出發，利用小步慢跑快速迭代 的思維去架構和演進項目才是王道。