為何要使用微服務方法來建立應用程式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 out or in, 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. 對於其他人而言,您從 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

當 Microsoft 從傳遞盒裝產品(通常是整合型)到提供服務時,就會發生 Azure Service Fabric。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. 轉換現有的整合型應用程式,或建立新的 greenfield 應用程式。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.

移轉Migrate
基於兩個原因,許多公司會將現有的整合型應用程式遷移到容器中: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.

現代化Modernize
現代化是隨著現有的容器化程式碼加入新服務。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.

創新Innovate
微服務方式能容納持續變更的商務需求。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. 容器和動作專案程式設計模型是該方向的小型步驟範例。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