在 Azure 上建置微服務Building microservices on Azure

微服務是熱門的架構樣式,用於建置可復原、高延展性、可獨立部署,以及能夠快速發展的應用程式。Microservices are a popular architectural style for building applications that are resilient, highly scalable, independently deployable, and able to evolve quickly. 但是成功的微服務架構需要不同的方法來設計和建置應用程式。But a successful microservices architecture requires a different approach to designing and building applications.

微服務架構是由一組小型的自發服務所組成。A microservices architecture consists of a collection of small, autonomous services. 每個服務各自獨立,並且應該實作單一的商務功能。Each service is self-contained and should implement a single business capability.


什麼是微服務?What are microservices?

  • 微服務屬於小型、獨立且鬆散結合的服務。Microservices are small, independent, and loosely coupled. 只要一小組開發人員即可撰寫和維護一個服務。A single small team of developers can write and maintain a service.

  • 每個服務都是個別的程式碼基底,可由小型的開發小組負責管理。Each service is a separate codebase, which can be managed by a small development team.

  • 服務可以獨立部署。Services can be deployed independently. 小組可以直接更新現有服務,而不需要重建和重新部署整個應用程式。A team can update an existing service without rebuilding and redeploying the entire application.

  • 服務需負責保存自己的資料或外部狀態。Services are responsible for persisting their own data or external state. 這一點不同於傳統模型,傳統模型是由個別資料層處理資料持續性。This differs from the traditional model, where a separate data layer handles data persistence.

  • 服務會使用妥善定義的 API 來彼此通訊。Services communicate with each other by using well-defined APIs. 每個服務的內部實作詳細資料都會對其他服務隱藏。Internal implementation details of each service are hidden from other services.

  • 服務不需要共用相同的技術堆疊、程式庫或架構。Services don't need to share the same technology stack, libraries, or frameworks.

除了服務本身外,典型的微服務架構中還會出現一些其他元件:Besides for the services themselves, some other components appear in a typical microservices architecture:

管理/協調流程Management/orchestration. 此元件負責將服務放在節點上、識別失敗、跨節點重新平衡服務等等。This component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth. 此元件通常是現成的技術,例如 Kubernetes,而不是自訂的建置專案。Typically this component is an off-the-shelf technology such as Kubernetes, rather than something custom built.

API 閘道API Gateway. API 閘道是用戶端的進入點。The API gateway is the entry point for clients. 用戶端會呼叫 API 閘道,然後再將呼叫轉送至後端的適當服務,而不會直接呼叫服務。Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end.

使用 API 閘道的優點包括:Advantages of using an API gateway include:

  • 它可讓用戶端與服務分離。It decouples clients from services. 服務可以控制版本或重構,而不需要更新所有的用戶端。Services can be versioned or refactored without needing to update all of the clients.

  • 服務可使用非專供 Web 使用的傳訊通訊協定,例如 AMQP。Services can use messaging protocols that are not web friendly, such as AMQP.

  • API 閘道可以執行其他跨領域功能,例如驗證、記錄、SSL 終止和負載平衡。The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.


  • 靈活度。Agility. 因為微服務為獨自部署,所以可更輕鬆地管理錯誤 (bug) 修正和功能版本。Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. 您可以逕自更新服務,而不必重新部署整個應用程式,並於發生錯誤時復原更新。You can update a service without redeploying the entire application, and roll back an update if something goes wrong. 在許多傳統的應用程式中,如果在應用程式的某個部分中發現錯誤 (bug),其可能會封鎖整個發行流程。In many traditional applications, if a bug is found in one part of the application, it can block the entire release process. 新功能可能會保留,等待整合、測試和發佈的錯誤修正。New features may be held up waiting for a bug fix to be integrated, tested, and published.

  • 小型焦點小組Small, focused teams. 微服務應小到讓單一功能小組可加以建置、測試及部署。A microservice should be small enough that a single feature team can build, test, and deploy it. 小型團隊規模可提升更大的靈活度。Small team sizes promote greater agility. 大型團隊的生產力可能較低,因為通訊速度較慢、管理額外負荷會增加,而靈活度會降低。Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.

  • 小型程式碼基底Small code base. 在單體式應用程式中,程式碼相依性有隨著時間變得紊亂的傾向,新增功能時需要碰觸許多位置的程式碼。In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. 微服務架構不會共用程式碼或資料存放區,因而降低相依性,並可讓您更輕鬆地新增功能。By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.

  • 混用技術Mix of technologies. 小組可以視情況使用混合的技術堆疊,以挑選出最適合其服務使用的技術。Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.

  • 錯誤隔離Fault isolation. 如果有個別微服務無法使用,只要有任何上游微服務是設計用來正確地處理錯誤 (例如,藉由實作線路中斷),就不會中斷整個應用程式。If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).

  • 延展性Scalability. 服務可以獨立延展,這可讓您相應放大需要更多資源的子系統,而不需相應放大整個應用程式。Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application. 使用 Kubernetes 或 Service Fabric 等協調器,您可以將大量服務封裝到單一主機,以達到更有效的資源使用率。Using an orchestrator such as Kubernetes or Service Fabric, you can pack a higher density of services onto a single host, which allows for more efficient utilization of resources.

  • 資料隔離Data isolation. 您可更輕鬆地執行結構描述更新,因為只有單一微服務受到影響。It is much easier to perform schema updates, because only a single microservice is affected. 在單體式應用程式中,結構描述更新可能變得非常具挑戰性,因為應用程式的不同組件可能會觸碰相同的資料,以致任何結構描述變化都有風險。In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.


微服務的權益不是免費提供。The benefits of microservices don't come for free. 著手進行微服務架構之前,應考慮以下一些挑戰。Here are some of the challenges to consider before embarking on a microservices architecture.

  • 複雜度Complexity. 微服務應用程式的變動組件數量比同等單體式應用程式的還多。A microservices application has more moving parts than the equivalent monolithic application. 每個服務會更為簡單,但是系統整個會變得更複雜。Each service is simpler, but the entire system as a whole is more complex.

  • 開發與測試Development and testing. 撰寫依賴其他相依服務的小型服務,需要不同於撰寫傳統單體式或分層式應用程式的方法。Writing a small service that relies on other dependent services requires a different approach than a writing a traditional monolithic or layered application. 現有工具的設計並非總是適用於處理服務相依性。Existing tools are not always designed to work with service dependencies. 跨服務界限進行重構會很困難。Refactoring across service boundaries can be difficult. 測試服務相依性也會很困難,尤其是當應用程式的演變速度很快時。It is also challenging to test service dependencies, especially when the application is evolving quickly.

  • 缺乏控管Lack of governance. 微服務的非集中式建置方法有其優點,卻也可能導致問題發生。The decentralized approach to building microservices has advantages, but it can also lead to problems. 您最終可能會有很多不同的語言和架構,而讓應用程式變得難以維護。You may end up with so many different languages and frameworks that the application becomes hard to maintain. 備有某些適用於全部專案的標準,而不要過度限制小組的彈性,這樣的做法可能會有幫助。It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. 這特別適用於跨領域功能,例如記錄。This especially applies to cross-cutting functionality such as logging.

  • 網路壅塞與延遲Network congestion and latency. 使用許多小型且細微的服務可能會導致服務之間需要更多通訊。The use of many small, granular services can result in more interservice communication. 此外,如果服務相依性鏈結太長 (服務 A 呼叫 B、B 再呼叫 C...),額外的延遲可能成為問題。Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem. 您將必須謹慎地設計 API。You will need to design APIs carefully. 請避免對話過度的 API、考慮使用序列化格式,並找找看有沒有地方可以使用非同步的通訊模式。Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.

  • 資料完整性Data integrity. 每個微服務負責維持自己的資料持續性。With each microservice responsible for its own data persistence. 因此,維持資料一致性會成為挑戰。As a result, data consistency can be a challenge. 可能的話,請採用最終一致性。Embrace eventual consistency where possible.

  • 管理Management. 想要成功運用微服務,就必須有成熟的 DevOps 文化。To be successful with microservices requires a mature DevOps culture. 在服務之間建立關聯式記錄會非常困難。Correlated logging across services can be challenging. 一般而言,記錄必須將多個服務呼叫相互關聯到單一使用者作業。Typically, logging must correlate multiple service calls for a single user operation.

  • 版本控制Versioning. 服務的更新不得打斷與其相依的服務。Updates to a service must not break services that depend on it. 多個服務有可能在同一時間一起更新,因此若未謹慎設計,便可能發生回溯相容性或往後相容性問題。Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

  • 技能集Skillset. 微服務是高度分散的系統。Microservices are highly distributed systems. 請謹慎評估小組是否有技能和經驗能夠成功。Carefully evaluate whether the team has the skills and experience to be successful.

建置微服務架構的流程Process for building a microservices architecture

此處所列的文章提供了設計、建置和操作微服務架構的一種結構方法。The articles listed here present a structured approach for designing, building, and operating a microservices architecture.

領域分析。Domain analysis. 若要在設計微服務時避免一些常見陷阱,請使用領域分析來定義您的微服務界限。To avoid some common pitfalls when designing microservices, use domain analysis to define your microservice boundaries. 請遵循下列步驟:Follow these steps:

  1. 使用領域分析進行微服務建模Use domain analysis to model microservices.
  2. 使用戰術性 DDD 來設計微服務Use tactical DDD to design microservices.
  3. 識別微服務界限Identify microservice boundaries.

設計服務Design the services. 微服務需要不同的方法來設計和建置應用程式。Microservices require a different approach to designing and building applications. 如需詳細資訊,請參閱設計微服務架構For more information, see Designing a microservices architecture.

生產運作Operate in production. 由於微服務架構是分散式的,因此您必須具備健全的作業才能進行部署和監視。Because microservices architectures are distributed, you must have robust operations for deployment and monitoring.