為何使用微服務方式建置應用程式?Why use a microservices approach to building applications?

適用於軟體開發人員,分解成元件部分的應用程式是什麼新玩意兒。For software developers, factoring an application into component parts is nothing new. 一般而言,一種分層的方法使用,以及後端存放區、 中間層商務邏輯和前端使用者介面 (UI)。Typically, a tiered approach is used, with a back-end store, middle-tier business logic, and a front-end user interface (UI). 什麼具有過去幾年來的變化是開發人員建置分散式的雲端應用程式。What has changed over the last few years is that developers are building distributed applications for the cloud.

以下是一些變動的業務需求:Here are some changing business needs:

  • 已建置並觸達新地理區域中的客戶大規模運作的服務。A service that's built and operated at scale to reach customers in new geographic regions.
  • 更快速的功能和功能,以回應客戶的需求,靈活地傳遞。Faster delivery of features and capabilities to respond to customer demands in an agile way.
  • 提高資源使用率來降低成本。Improved resource utilization to reduce costs.

這些商務需求會影響我們「如何」 建置應用程式。These business needs are affecting how we build applications.

如需有關 Azure 微服務方法的詳細資訊,請參閱微服務:採用雲端技術的應用程式革命For more information about the Azure approach to microservices, see Microservices: An application revolution powered by the cloud.

整合型與微服務設計方法Monolithic vs. microservices design approach

應用程式會隨著時間而演化。Applications evolve over time. 成功的應用程式因為有實用性而演化。Successful applications evolve by being useful to people. 失敗的應用程式不發展,並最終已被取代。Unsuccessful applications don't evolve and are eventually deprecated. 以下是這個問題: 多少執行您現在了解您的需求,它們會在未來很嗎?Here's the question: how much do you know about your requirements today and what they'll be in the future? 例如,假設您要建置某部門的報告應用程式在您的公司。For example, let's say you're building a reporting application for a department in your company. 您確定應用程式適用於只能在貴公司的範圍內,而且報表將不會保留的長。You're sure the application applies only within the scope of your company and that the reports won't be kept long. 您的方法就是不同的說,建置服務視訊內容傳遞給數千萬個客戶。Your approach will be different from that of, say, building a service that delivers video content to tens of millions of customers.

有時向外尋求概念證明才是驅動因素。Sometimes, getting something out the door as a proof of concept is the driving factor. 您知道應用程式可以在稍後重新設計。You know the application can be redesigned later. 有太大的工程過度複雜化的項目永遠不會取得使用。There's little point in over-engineering something that never gets used. 相反地,當公司建置雲端時,預期會成長和使用量。On the other hand, when companies build for the cloud, the expectation is growth and usage. 成長和範圍會無法預測。Growth and scale are unpredictable. 我們想要的原型快速同時還要了解,我們在可以處理未來成功的路徑。We want to prototype quickly while also knowing that we're on a path that can handle future success. 這是精簡的創業方法:建置、測量、學習及反覆執行。This is the lean startup approach: build, measure, learn, and iterate.

在用戶端/伺服器時代,我們傾向專注於建立分層式應用程式使用每個層中的特定技術。During the client/server era, we tended to focus on building tiered applications by using specific technologies in each tier. 詞彙單體式應用程式已描述這些方法衍生出。The term monolithic application has emerged to describe these approaches. 介面通常存在於各層之間,而在各層內的元件之間採用更緊密結合的設計。The interfaces tended to be between the tiers, and a more tightly coupled design was used between components within each tier. 開發人員設計並分解類別,已編譯成程式庫,並連結起來成為一些可執行檔和 Dll。Developers designed and factored classes that were compiled into libraries and linked together into a few executable files and DLLs.

有許多優點,整合型設計的做法。There are benefits to a monolithic design approach. 整合型應用程式通常用來設計、 更簡單,元件之間的呼叫會比較快,因為這些呼叫通常是透過處理序間通訊 (IPC)。Monolithic applications are often simpler to design, and calls between components are faster because these calls are often over interprocess communication (IPC). 此外,所有人測試單一產品,通常是人力資源更有效率地使用。Also, everyone tests a single product, which tends to be a more efficient use of human resources. 缺點是分層式的層級之間的結合緊密,且您無法調整個別的元件。The downside is that there's a tight coupling between tiered layers, and you can't scale individual components. 如果您需要執行修正或升級,您必須等候其他人完成其測試。If you need to do fixes or upgrades, you have to wait for others to finish their testing. 它是很難敏捷式軟體開發。It's harder to be agile.

微服務可解決這些缺點,更密切配合上述的商務需求。Microservices address these downsides and more closely align with the preceding business requirements. 但它們也有優點和責任。But they also have both benefits and liabilities. 微服務的優點在於其通常會封裝較簡單的商務功能,因此您可以獨立地對它們進行相應增加或減少、測試、部署,以及管理。The benefits of microservices are that each one typically encapsulates simpler business functionality, which you can scale up or down, test, deploy, and manage independently. 微服務方法的一個重要優點是團隊會驅動商務案例的更多的技術。One important benefit of a microservices approach is that teams are driven more by business scenarios than by technology. 較小的小組開發的客戶案例為基礎的微服務,並使用他們想要使用的任何技術。Smaller teams develop a microservice based on a customer scenario and use any technologies that they want to use.

換句話說,組織不需要為了維護微服務應用程式而將技術標準化。In other words, the organization doesn’t need to standardize tech to maintain microservice applications. 擁有服務的個別團隊可以根據團隊的專業知識,或什麼是最適合所要解決的問題,各自發揮所長。Individual teams that own services can do what makes sense for them based on team expertise or what’s most appropriate to solve the problem. 在實務上,一組建議的技術,例如特定的 NoSQL 存放區或 web 應用程式架構,最好。In practice, a set of recommended technologies, like a particular NoSQL store or web application framework, is preferable.

微服務的缺點是,您必須管理多個個別的實體,以及處理更複雜的部署和版本控制。The downside of microservices is that you have to manage more separate entities and deal with more complex deployments and versioning. 微服務之間的網路流量增加時,如同對應的網路延遲。Network traffic between the microservices increases, as do the corresponding network latencies. 許多多對話且細微的服務可能會導致效能夢魘的解決。Lots of chatty, granular services can cause a performance nightmare. 沒有工具可協助您檢視這些相依性,就很難看到整個系統項目。Without tools to help you view these dependencies, it's hard to see the whole system.

標準會讓微服務方法,藉由指定的通訊方式,並容許只在乎您需要從服務中,工作而不是僵固的合約。Standards make the microservices approach work by specifying how to communicate and tolerating only the things you need from a service, rather than rigid contracts. 請務必在設計中定義這些合約,因為服務彼此獨立地更新。It's important to define these contracts up front in the design because services update independently of each other. 另一個在設計微服務方法時出現的描述是「細緻的服務導向架構 (SOA)」。Another description coined for designing with a microservices approach is “fine-grained service-oriented architecture (SOA).”

簡單來說,微服務設計方法是低耦合的服務同盟,各自獨立變更和同意標準的通訊。At its simplest, the microservices design approach is about a decoupled federation of services, with independent changes to each and agreed-upon standards for communication.

隨著更多的雲端應用程式產生,人們發現這種分解成獨立、 案例焦點式服務的整體應用程式是更好的長期的方法。As more cloud applications are produced, people have discovered that this decomposition of the overall application into independent, scenario-focused services is a better long-term approach.

應用程式開發方法的比較Comparison between application development approaches

Service Fabric 平台應用程式開發

  1. 單體式應用程式包含領域特定功能,而且通常分成功能層級,例如 web、 商務和資料。A monolithic application contains domain-specific functionality and is normally divided into functional layers like web, business, and data.

  2. 您可藉由複製到多個伺服器/虛擬機器上調整整合型應用程式/容器。You scale a monolithic application by cloning it on multiple servers/virtual machines/containers.

  3. 微服務應用程式會將個別功能分隔成個別較小的服務。A microservice application separates functionality into separate smaller services.

  4. 微服務方法可獨立部署每個服務而相應放大,跨伺服器/虛擬機器/容器建立這些服務的執行個體。The microservices approach scales out by deploying each service independently, creating instances of these services across servers/virtual machines/containers.

使用微服務設計方法並不適用於所有專案,但確實更接近稍早所述的商務目標。Designing with a microservices approach isn't appropriate for all projects, but it does align more closely with the business objectives described earlier. 從使用單體式方法開始合理如果您知道您將有機會將程式碼修改為微服務設計的更新版本。Starting with a monolithic approach might make sense if you know you'll have the opportunity to rework the code later into a microservices design. 較常見的情況是您從單體式應用程式開始著手,然後從需要更高調整性或靈活度的功能領域開始,分階段緩慢地將它拆解。More commonly, you begin with a monolithic application and slowly break it up in stages, starting with the functional areas that need to be more scalable or agile.

當您使用微服務方法時,您會撰寫您的應用程式的許多小型服務。When you use a microservices approach, you compose your application of many small services. 這些服務會在部署於電腦叢集的容器中執行。These services run in containers that are deployed across a cluster of machines. 較小的團隊會開發著重於某個案例的服務和獨立測試版本、 部署及調整每個服務,讓整個應用程式就能持續改進的資料。Smaller teams develop a service that focuses on a scenario and independently test, version, deploy, and scale each service so the entire application can evolve.

什麼是微服務?What is a microservice?

有不同的微服務定義。There are different definitions of microservices. 不過,大部分的微服務的這些特性會被廣泛接受:But most of these characteristics of microservices are widely accepted:

  • 封裝客戶或商務案例。Encapsulate a customer or business scenario. 您解決什麼問題?What problem are you solving?
  • 由小型工程團隊開發。Developed by a small engineering team.
  • 以任何程式設計語言,使用任何架構。Written in any programming language, using any framework.
  • 包含程式碼,以及 (選擇性) 狀態,這兩者都是獨立控制版本、 部署及調整。Consist of code, and optionally state, both of which are independently versioned, deployed, and scaled.
  • 透過定義完善的介面和通訊協定,與其他微服務互動。Interact with other microservices over well-defined interfaces and protocols.
  • 具有用來解析其位置的唯一名稱 (Url)。Have unique names (URLs) that are used to resolve their location.
  • 在失敗時維持一致且可用的。Remain consistent and available in the presence of failures.

總而言之,:To sum that up:

微服務應用程式是由獨立控制版本和可調整的客戶焦點式服務所組成,這些服務透過標準通訊協定和定義完善的介面彼此通訊。Microservice applications are composed of small, independently versioned, and scalable customer-focused services that communicate with each other over standard protocols with well-defined interfaces.

以任何程式設計語言,使用任何架構Written in any programming language, using any framework

身為開發人員,我們想要可自由選擇的語言或架構,根據本身的技術和服務,我們要建立的需求而定。As developers, we want to be free to choose a language or framework, depending on our skills and the needs of the service that we're creating. 某些服務中,您可能值的效能優勢C++上述任何其他項目。For some services, you might value the performance benefits of C++ above anything else. 對於其他人,方便您從取得的 managed 開發C#或 Java 可能更為重要。For others, the ease of managed development that you get from C# or Java might be more important. 在某些情況下,您可能需要使用特定的協力廠商程式庫、 資料儲存技術或方法來公開給用戶端服務。In some cases, you might need to use a specific partner library, data storage technology, or method for exposing the service to clients.

您選擇技術之後,您需要考慮操作或生命週期管理和調整服務。After you choose a technology, you need to consider the operational or life-cycle management and scaling of the service.

允許獨立控制版本、部署及調整的程式碼和狀態Allows code and state to be independently versioned, deployed, and scaled

不論您如何撰寫您的微服務、 程式碼,以及 (選擇性) 狀態,應該獨立部署、 升級和調整。No matter how you write your microservices, the code, and optionally the state, should independently deploy, upgrade, and scale. 這個問題很難解決因為這涉及到您選擇的技術。This problem is hard to solve because it comes down to your choice of technologies. 調整,了解如何分割 (或分區) 的程式碼和狀態是一項挑戰。For scaling, understanding how to partition (or shard) both the code and the state is challenging. 當程式碼和狀態使用不同的技術,這是常見的今日,您的微服務的部署指令碼必須能夠調整兩者。When the code and state use different technologies, which is common today, the deployment scripts for your microservice need to be able to scale them both. 這種區隔也是關乎靈活度和彈性,因此您可以升級部分微服務而不必一次全部升級。This separation is also about agility and flexibility, so you can upgrade some of the microservices without having to upgrade all of them at once.

讓我們回到我們的時刻的單體式和微服務方法的比較。Let's return to our comparison of the monolithic and microservices approaches for a moment. 下圖顯示儲存狀態的方法中的差異:This diagram shows the differences in the approaches to storing state:

兩種方法狀態儲存體State storage for the two approaches

Service Fabric 平台狀態儲存體

單體式方法中,在左邊,有一個單一資料庫和多層的特定技術。The monolithic approach, on the left, has a single database and tiers of specific technologies.

微服務方法中,在右側,有圖形顯示互連的微服務,其中狀態通常以微服務為範圍,並會使用各種技術。The microservices approach, on the right, has a graph of interconnected microservices where state is typically scoped to the microservice and various technologies are used.

在單體式方法中,應用程式通常會使用單一資料庫。In a monolithic approach, the application typically uses a single database. 使用一個資料庫的優點是它是在單一位置,可讓您更容易部署。The advantage to using one database is that it's in a single location, which makes it easy to deploy. 每個元件可以有單一資料表來儲存其狀態。Each component can have a single table to store its state. 挑戰之處在於團隊必須嚴格區分狀態。Teams need to strictly separate state, which is a challenge. 無可避免地,有人會想要加入至現有的客戶資料表的資料行、 資料表之間的聯結作業,並建立儲存層的相依性。Inevitably, someone will be tempted to add a column to an existing customer table, do a join between tables, and create dependencies at the storage layer. 發生這種情況後,您無法調整個別的元件。After this happens, you can't scale individual components.

在微服務方法中,每個服務都會管理並儲存自己的狀態。In the microservices approach, each service manages and stores its own state. 每個服務負責同時調整程式碼和狀態,以滿足服務的需求。Each service is responsible for scaling both code and state together to meet the demands of the service. 缺點是,當您需要建立檢視或查詢,您的應用程式資料,您需要跨多個狀態存放區進行查詢。A downside is that when you need to create views, or queries, of your application’s data, you need to query across multiple state stores. 通常由個別的微服務可跨微服務的集合中建立檢視之後,即可解決此問題。This problem is typically solved by a separate microservice that builds a view across a collection of microservices. 如果您需要對資料執行多個即席查詢,您應該考慮將每個微服務的資料寫入至資料倉儲服務,供離線分析。If you need to run multiple impromptu queries on the data, you should consider writing each microservice’s data to a data warehousing service for offline analytics.

微服務的版本。Microservices are versioned. 可以針對不同版本的並存執行微服務。It's possible for different versions of a microservice to run side by side. 新版的微服務無法在升級期間失敗,而且需要回復至舊版。A newer version of a microservice could fail during an upgrade and need to be rolled back to an earlier version. 版本控制也很有用的 A / B 測試,其中不同的使用者體驗到不同版本的服務。Versioning is also helpful for A/B testing, where different users experience different versions of the service. 比方說,常會升級的一組特定客戶來測試新的功能,然後再發送更廣泛的微服務。For example, it's common to upgrade a microservice for a specific set of customers to test new functionality before rolling it out more widely.

透過定義完善的介面和通訊協定,與其他微服務互動Interacts with other microservices over well-defined interfaces and protocols

在過去 10 年來,廣泛的資訊已發行描述服務導向架構中的通訊模式。Over the past 10 years, extensive information has been published describing communication patterns in service-oriented architectures. 一般而言,服務通訊使用 REST 方法,並搭配 HTTP 和 TCP 通訊協定及 XML 或 JSON 做為序列化格式。Generally, service communication uses a REST approach with HTTP and TCP protocols and XML or JSON as the serialization format. 從介面觀點來看,它是有關採用 web 設計方法。From an interface perspective, it's about taking a web design approach. 但是,不應該讓您無法使用二進位通訊協定或您自己的資料格式。But nothing should stop you from using binary protocols or your own data formats. 只要留意人們將擁有更難使用您的微服務,如果這些通訊協定和格式無法公開使用的時間。Just be aware that people will have a harder time using your microservices if these protocols and formats aren't openly available.

具有可用來解析位置的唯一名稱 (URL)Has a unique name (URL) used to resolve its location

您的微服務必須是可定址的只要它正在執行。Your microservice needs to be addressable wherever it's running. 如果您正在考慮機器及哪一個執行特定的微服務,項目可以急遽惡化。If you're thinking about machines and which one is running a particular microservice, things can go bad quickly.

就像 DNS 會解析特定電腦的特定 URL 一樣,微服務需要有唯一的名稱,其目前所在的位置才可被探索。In the same way that DNS resolves a particular URL to a particular machine, your microservice needs a unique name so that its current location is discoverable. 微服務需要可定址的名稱,都是獨立的執行所在的基礎結構。Microservices need addressable names that are independent of the infrastructure they're running on. 這表示沒有之間如何部署您的服務和探索方式,因為需要有服務登錄。This implies that there's an interaction between how your service is deployed and how it's discovered, because there needs to be a service registry. 當電腦故障時,登錄服務必須告訴您該服務已移至。When a machine fails, the registry service needs to tell you where the service was moved to.

失敗時維持一致且可用Remains consistent and available in the presence of failures

處理非預期的失敗是最難解決的問題之一,特別是在分散式系統中。Dealing with unexpected failures is one of the hardest problems to solve, especially in a distributed system. 大部分開發人員撰寫的程式碼會處理例外狀況。Much of the code that we write as developers is for handling exceptions. 在測試期間,我們也花最多時間在例外狀況處理。During testing, we also spend the most time on exception handling. 此程序會比撰寫程式碼來處理失敗更為複雜。The process is more involved than writing code to handle failures. 微服務執行所在的電腦失敗時,會發生什麼事?What happens when the machine on which the microservice is running fails? 您要偵測到失敗,也就是在它自己的難題。You need to detect the failure, which is a hard problem on its own. 但您也需要重新啟動您的微服務。But you also need to restart your microservice.

如需可用性,微服務必須從失敗中復原,以在另一部電腦上重新啟動。For availability, a microservice needs to be resilient to failures and able to restart on another machine. 除了這些的復原需求,資料應該不會遺失,而且資料必須維持一致。In addition to these resiliency requirements, data shouldn't be lost, and data needs to remain consistent.

如果在應用程式升級期間發生失敗,會使復原性很難達成。Resiliency is hard to achieve when failures happen during an application upgrade. 在搭配部署系統一起運作時,微服務不需要復原。The microservice, working with the deployment system, doesn't need to recover. 它需要決定是否可以繼續向前移到較新版本,或回復至先前的版本,以維護一致的狀態。It needs to determine whether it can continue to move forward to the newer version or roll back to a previous version to maintain a consistent state. 您必須考慮幾個問題,例如足夠的電腦是否可繼續升級,以及如何復原舊版的微服務。You need to consider a few questions, like whether enough machines are available to keep moving forward and how to recover previous versions of the microservice. 若要做出這些決定,您會需要微服務發出健康情況資訊。To make these decisions, you need the microservice to emit health information.

報告狀況和診斷Reports health and diagnostics

它可能就很明顯,常被忽略,但微服務必須報告其健全狀況和診斷。It might seem obvious, and it's often overlooked, but a microservice needs to report its health and diagnostics. 否則,您必須從作業觀點來看其健全狀況的深入。Otherwise, you have little insight into its health from an operations perspective. 相互關聯一組獨立服務上的診斷事件,並處理電腦時間差異以了解事件順序,是一件非常具挑戰性的任務。Correlating diagnostic events across a set of independent services, and dealing with machine clock skews to make sense of the event order, is challenging. 與您透過同意的通訊協定和資料格式來與微服務互動相同,您需要將健康情況和診斷事件的記錄方式標準化,因為這些事件最後會被放入事件存放區中以供查詢和檢視。In the same way that you interact with a microservice over agreed-upon protocols and data formats, you need to standardize how to log health and diagnostic events that will ultimately end up in an event store for querying and viewing. 使用微服務方法時,不同的小組需要同意單一記錄格式。With a microservices approach, different teams need to agree on a single logging format. 需要有一致的方法可檢視整個應用程式中的診斷事件。There needs to be a consistent approach to viewing diagnostic events in the application as a whole.

狀況與診斷不同。Health is different from diagnostics. 健全狀況是指微服務報告其目前狀態,以便採取適當的行動。Health is about the microservice reporting its current state to take appropriate actions. 使用升級和部署機制來維護可用性是一個很好例子。A good example is working with upgrade and deployment mechanisms to maintain availability. 雖然服務可能是因為處理序損毀的目前狀況不良,或重新開機,服務可能仍會運作。Though a service might be currently unhealthy because of a process crash or machine reboot, the service might still be operational. 開始升級讓情況更糟的是為您所需要的最後一件事。The last thing you need is to make the situation worse by starting an upgrade. 最好的方法是先調查或讓微服務,可復原的時間。The best approach is to investigate first or allow time for the microservice to recover. 微服務的健全狀況事件可協助我們做出明智的決策,實際上有助於建立自我修復的服務。Health events from a microservice help us make informed decisions and, in effect, help create self-healing services.

設計微服務在 Azure 上的指引Guidance for designing microservices on Azure

造訪 Azure 架構中心指引設計和建置在 Azure 上的微服務Visit the Azure architecture center for guidance on designing and building microservices on Azure.

Service Fabric 做為微服務平台Service Fabric as a microservices platform

Azure Service Fabric 源自於 Microsoft 從提供盒裝的產品,通常是單體,到提供服務的轉換時。Azure Service Fabric emerged when Microsoft transitioned from delivering boxed products, which were typically monolithic, to delivering services. 建置和操作大型服務,例如 Azure SQL Database 和 Azure Cosmos DB 的經驗圖形化 Service Fabric。The experience of building and operating large services, like Azure SQL Database and Azure Cosmos DB, shaped Service Fabric. 如需詳細的服務採用隨時間而變化的平台。The platform evolved over time as more services adopted it. Service Fabric 不僅必須在 Azure 中執行,也必須在獨立式 Windows Server 部署中執行。Service Fabric had to run not only in Azure but also in standalone Windows Server deployments.

Service Fabric 的目標是解決建置和執行服務的艱難的問題並有效地使用基礎結構資源,讓小組可以使用微服務方法解決商務問題。The aim of Service Fabric is to solve the hard problems of building and running a service and to use infrastructure resources efficiently, so teams can solve business problems by using a microservices approach.

Service Fabric 透過提供下列項目,來協助您使用微服務方法建置應用程式:Service Fabric helps you build applications that use a microservices approach by providing:

  • 一個提供系統服務的平台 - 這些服務可進行部署、升級、偵測及重新啟動失敗的服務、探索服務、路由傳送訊息、管理狀態,以及監視健康情況。A platform that provides system services to deploy, upgrade, detect, and restart failed services, discover services, route messages, manage state, and monitor health.
  • 部署應用程式容器中或做為處理序: 執行的能力。The ability to deploy applications either running in containers or as processes. Service Fabric 是一個容器和處理序協調者。Service Fabric is a container and process orchestrator.
  • 高生產力程式設計 Api,用來協助您建置成微服務的應用程式:ASP.NET Core、Reliable Actors 及 Reliable ServicesProductive programming APIs to help you build applications as microservices: ASP.NET Core, Reliable Actors, and Reliable Services. 例如,您可以取得健康情況和診斷資訊,或利用內建的高可用性。For example, you can get health and diagnostics information, or you can take advantage of built-in high availability.

關於如何建置您的服務,Service Fabric 無關,而且您可以使用任何技術。但是,它提供內建的程式設計 Api,讓您更輕鬆地建置微服務。Service Fabric is agnostic about how you build your service, and you can use any technology. But it does provide built-in programming APIs that make it easier to build microservices.

將現有的應用程式移轉到 Service FabricMigrating existing applications to Service Fabric

Service Fabric 可讓您重複使用現有的程式碼,並將它與新的微服務的現代化。Service Fabric allows you to reuse existing code and modernize it with new microservices. 有應用程式的現代化的五個階段,您可以啟動和停止每一個階段。There are five stages to application modernization, and you can start and stop at any stage. 階段是:The stages are:

  1. 開始使用傳統單體式應用程式。Start with a traditional monolithic application.
  2. 移轉。Migrate. 使用容器或來賓可執行檔來裝載 Service Fabric 中的現有程式碼。Use containers or guest executables to host existing code in Service Fabric.
  3. 現代化。Modernize. 加入新的微服務與現有的容器化程式碼。Add new microservices alongside existing containerized code.
  4. 創新。Innovate. 整合型應用程式分成需求為基礎的微服務。Break the monolithic application into microservices based on need.
  5. 轉換成微服務的應用程式。Transform applications into microservices. 轉換現有的單體式應用程式,或建立新的原創應用程式。Transform existing monolithic applications or build new greenfield applications.


請記住,您可以在當中任何階段開始和停止Remember, you can start and stop at any of these stages. 您不需要進行至下一個階段。You don't have to progress to the next stage.

讓我們看看範例的每個階段。Let's look at examples for each of these stages.

基於兩個理由,許多公司都要移轉現有的單體式應用程式,在容器:For two reasons, many companies are migrating existing monolithic applications into containers:

  • 降低成本,可能是因為合併和移除現有的硬體或執行應用程式在更高的密度。Cost reduction, either due to consolidation and removal of existing hardware or due to running applications at higher density.
  • 開發與作業之間的一致性部署合約。A consistent deployment contract between development and operations.

降低成本是直接了當。Cost reductions are straightforward. 在 Microsoft,許多現有的應用程式都正透過容器化,導致節省數百萬美元。At Microsoft, many existing applications are being containerized, leading to millions of dollars in savings. 一致性部署較難以評估,但同樣重要。Consistent deployment is harder to evaluate but equally important. 這表示,開發人員可以選擇的技術,符合它們,但是作業會接受單一方法來部署及管理應用程式。It means that developers can choose the technologies that suit them, but operations will accept only a single method for deploying and managing the applications. 它可減輕作業的處理支援不同的技術,不強迫開發人員可以選擇只將特定技術的複雜性。It alleviates operations from having to deal with the complexity of supporting different technologies without forcing developers to choose only certain ones. 基本上,每個應用程式是透過容器化成為獨立性的部署映像。Essentially, every application is containerized into self-contained deployment images.

許多組織都在此停止。Many organizations stop here. 他們已經有容器的優點和 Service Fabric 會提供完整的管理體驗,包括部署、 升級、 版本控制、 復原、 和健全狀況監視。They already have the benefits of containers, and Service Fabric provides the complete management experience, including deployment, upgrades, versioning, rollbacks, and health monitoring.

現代化,是加入新的服務與現有的容器化程式碼。Modernization is the addition of new services alongside existing containerized code. 如果您要撰寫新程式碼,最好是採取小型微服務的路徑下的步驟。If you're going to write new code, it's best to take small steps down the microservices path. 這可能表示新增新的 REST API 端點或新的商務邏輯。This could mean adding a new REST API endpoint or new business logic. 如此一來,您可以開始建置新微服務,以及練習開發和部署程序。In this way, you start the process of building new microservices and practice developing and deploying them.

微服務方式能容納持續變更的商務需求。A microservices approach accommodates changing business needs. 在這個階段,您必須決定是否要開始分割單體式應用程式服務,或進行創新。At this stage, you need to decide whether to start splitting the monolithic application into services, or innovating. 一個典型的範例時,您用來作為工作流程佇列的資料庫會變成處理瓶頸。A classic example here is when a database that you're using as a workflow queue becomes a processing bottleneck. 隨著工作流程要求數目的增加,將需要分配工作來進行調整。As the number of workflow requests increases, the work needs to be distributed for scale. 需要這部分的應用程式,不能擴充,或需要更頻繁地更新並將它分割為微服務及創新。Take that particular piece of the application that's not scaling, or that needs to be updated more frequently, and split it out as a microservice and innovate.

轉換成微服務的應用程式Transform applications into microservices
在這個階段,您的應用程式是完全組成 (或分成) 微服務。At this stage, your application is fully composed of (or split into) microservices. 若要達到這個點,您所做的微服務旅程圖。To reach this point, you've made the microservices journey. 您可以從這裡開始,但若要這樣做沒有用微服務平台,可協助您需要大量投資。You can start here, but to do so without a microservices platform to help you requires a significant investment.

微服務適合我的應用程式嗎?Are microservices right for my application?

可能。Maybe. 在 Microsoft,隨著更多小組開始建置雲端商務原因,其中有許多實現採用類似微服務的方法的優點。At Microsoft, as more teams began to build for the cloud for business reasons, many of them realized the benefits of taking a microservice-like approach. Bing,比方說,有已使用微服務一年。Bing, for example, has been using microservices for years. 對於其他團隊而言,微服務方法很新穎。For other teams, the microservices approach was new. 團隊發現在他們的核心強項之外,還有需要解決的困難問題。Teams found that there were hard problems to solve outside of their core areas of strength. 這就是為什麼 Service Fabric 重視而成為建置服務的技術。This is why Service Fabric gained traction as the technology for building services.

Service Fabric 的目標是減少建置微服務應用程式,讓您不需要經歷多個高成本的重新設計的複雜性。The objective of Service Fabric is to reduce the complexities of building microservice applications so that you don't have to go through as many costly redesigns. 從小規模開始、需要時調整、淘汰服務、加入新服務,並隨客戶使用情況而演化。Start small, scale when needed, deprecate services, add new ones, and evolve with customer usage. 我們也知道,為了讓微服務更易於為大部分開發人員所接受,還有許多其他尚待解決的問題。We also know that there are many other problems yet to be solved to make microservices more approachable for most developers. 容器和 actor 程式設計模型是簡單的步驟,在該方向中的範例。Containers and the actor programming model are examples of small steps in that direction. 我們確定更多創新便會浮現讓微服務方法更容易。We're sure more innovations will emerge to make a microservices approach easier.

後續步驟Next steps