Pattern: Microservices Architecture
Context
You are developing a server-side enterprise application. It must support a variety of different clients including desktop browsers, mobile browsers and native mobile applications. The application might also expose an API for 3rd parties to consume. It might also integrate with other applications via either web services or a message broker. The application handles requests (HTTP requests and messages) by executing business logic; accessing a database; exchanging messages with other systems; and returning a HTML/JSON/XML response.
The application has either a layered or hexagonal architecture and consists of different types of components:
- Presentation components - responsible for handling HTTP requests and responding with either HTML or JSON/XML (for web services APIS)
- Business logic - the applicationrsquo;s business logic
- Database access logic - data access objects responsible for access the database
- Application integration logic - messaging layer, e.g. based on Spring integration.
There are logical components corresponding to different functional areas of the application.
Problem
Whats the applications deployment architecture?
Forces
- There is a team of developers working on the application
- New team members must quickly become productive
- The application must be easy to understand and modify
- You want to practice continuous deployment of the application
- You must run multiple copies of the application on multiple machines in order to satisfy scalability and availability requirements
- You want to take advantage of emerging technologies (frameworks, programming languages, etc)
Solution
Architect the application by applying the Scale Cube (specifically y-axis scaling) and functionally decompose the application into a set of collaborating services. Each service implements a set of narrowly, related functions. For example, an application might consist of services such as the order management service, the customer management service etc.
Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP.
Services are developed and deployed independently of one another.
Each service has its own database in order to be decoupled from other services. When necessary, consistency is between databases is maintained using either database replication mechanisms or application-level events.
Example
Letrsquo;s imagine that you are building an e-commerce application that takes orders from customers, verifies inventory and available credit, and ships them. The application consists of several components including the StoreFrontUI, which implements the user interface, along with some backend services for checking credit, maintaining inventory and shipping orders.
The application is deployed as a set of services.
Resulting context
This solution has a number of benefits:
-
Each microservice is relatively small
- Easier for a developer to understand
- The IDE is faster making developers more productive
- The web container starts faster, which makes developers more productive, and speeds up deployments
- Each service can be deployed independently of other services - easier to deploy new versions of services frequently
- Easier to scale development. It enables you to organize the development effort around multiple teams. Each (two pizza) team is responsible a single service. Each team can develop, deploy and scale their service independently of all of the other teams.
- Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests. In comparison, one misbehaving component of a monolithic architecture can bring down the entire system.
- Each service can be developed and deployed independently
- Eliminates any long-term commitment to a technology stack
This solution has a number of drawbacks:
-
Developers must deal with the additional complexity of creating a distributed system.
- Developer tools/IDEs are oriented on building monolithic applications and dont provide explicit support for developing distributed applications.
- Testing is more difficult
- Developers must implement the inter-service communication mechanism.
- Implementing use cases that span multiple services without using distributed transactions is difficult
- Implementing use cases that span multiple services requires careful coordination between the teams
- Deployment complexity. In production, there is also the operational complexity of deploying and managing a system comprised of many different service types.
- Increased memory consumption. The microservices architecture replaces N monolithic application instances with NxM services instances. If each service runs in its own JVM (or equivalent), which is usually necessary to isolate the instances, then there is the overhead of M times as many JVM runtimes. Moreover, if each service runs on its own VM (e.g. EC2 instance), as is the case at Netflix, the overhead is even higher.
One challenge with using this approach is deciding when it makes sense to use it. When developing the first version of an application, you often do not have the problems that this approach solves. Moreover, using an elaborate, distributed architecture will slow down development. This can be a major problem for startups whose biggest challenge is often how to rapidly evolve the business model and accompanying application. Using Y-axis splits might make it much more diff
剩余内容已隐藏，支付完成后下载完整资料
原文地址：http://microservices.io/patterns/microservices.html
模式：微服务架构
背景：
当你要开发服务端的企业级应用，它一般要支持各种各样的客户端，包括PC浏览器，移动设备浏览器和原生应用。通常，应用还会暴露相关接口供第三方调用。并且应用有可能通过web services 或者消息中间件来集成其它应用。应用处理请求（HTTP请求和消息）过程包括执行业务逻辑的、访问数据库、和其它系统交换消息、返回HTML/JSON/XML响应。
一个具有分层架构的应用包含以下几种不同类型的组件：
- 表现层组件：负责处理HTTP请求并返回HTML/JSON/XML视图
- 业务逻辑层：应用的业务逻辑。
- 数据库访问层：通过应用实体对象来访问数据库。
- 应用集成组件：消息通信层，例如基于Spring的集成。
问题：
应用的部署架构是什么？
现状：
- 一个应用由一个团队在负责开发。
- 团队的新成员需要快速地投入生产中。
- 应用需要便于理解和修改。
- 想要实践应用的持续交付。
- 需要通过将同一个应用代码运行在多个服务器上，来适应对于规模、可用性的需求。
- 想要利用各个种技术优点（例如，框架、编程语言等）
解决方案：
通过应用Scale Cube（特别是Y轴的扩展）架构和将应用从功能角度分解成一组相互协作的服务。每个服务实现一组相关联的功能。举个例子，一个应用可能包含订单管理服务，用户管理服务等。
服务之前通信可以通过同步接口（例如HTTP/REST）或者异步接口（例如AMQP）。
每组服务可以独立开发和部署。
例子：
让我们来以建立一个电子商务系统为例子，通常该系统包括顾客下订单、检查库存、有效的支付、物流配送。系统由多个组件组成，其中包括显示用户界面的店铺前台，和后台的支付检查、库存管理、物流服务。
系统通常作为一系列的服务来发布。
结论：
这种解决方案有以下几个优点：
- 每一个微服务相对较小
- 开发者更加容易理解。
- IDE的运行速度更快，提高开发者生产效率。
- WEB容器启动更快，加速系统部署。
- 每一个服务可以独立的发布-可以更加容易提高发布频率。
- 使规模化开发更简单。每一个团队负责一个单独的服务。每一个团队可以开发、部署、规模化自己服务而独立于其它团队。
- 提高错误孤立性。例如，如果有个一服务发生内存泄漏，而这仅仅会影响当前服务，其它服务将继续处理请求。相反，对于单块架构，一个组件异常将会拖垮整个系统。
- 每一个服务可以被独立开发和部署。
- 减少对某一种技术栈的长期依赖。
缺点：
- 开发者需要解决由分布式系统带来的复杂性
- 开发工具或者IDE面向的是单块应用而没有提供特别针对开发分布式系统的支持。
- 测试将更加困难。
- 开发者需要实现与其它服务通讯方法。
- 实现调用多个服务而不采用分布式事务是一件非常困难事情。
- 实现调用多个服务需要在团队之间采用非常谨慎的协商。
- 部署复杂性。在生产环境中，部署和管理一个包含多个类型服务的操作是复杂的。
- 增加了内存消耗。N*M服务实例的微服务架构取代了以往N个单块应用实例的方式。如果每一个服务需要运行在自己的JVM实例中，这通常需要隔离每个实例,此时将有M个JVM运行时的开销。如果每个服务运行在独立的虚拟机中（例如 EC2），如Netflix公司，总的开销将更多。
对于我们应用该方法时一个重大的挑战就是什么时候合理去使用。当我们开发第一版本的应用时候，并不会有现状中描述的问题。此外，使用复杂的分布式架构反而减慢开发速度。而此时主要挑战是如何快速解决业务模型和开发相应的应用。
“微服务” - 软件架构拥挤大街上的有一个新术语。虽然我们自然的倾向是轻蔑的一瞥将它一带而过，然而我们发现这一术语描述了一种越来越吸引人的软件系统风格。我们已看到，在过去的几年中有许多项目使用了这种风格，并且到目前为止结果都还不错，以致于这已变成了我们同事在构建企业级应用程序时默认使用的架构风格。然而，遗憾的是并没有太多的信息来概述什么是微服务风格以及怎样用这种风格。
简单来说，微服务架构风格1是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
与单体风格作对比有助于开始解释微服务风格：单体应用程序被构建为单一单元。企业级应用程序通常由三部分组成：客户端侧用户接口(由运行于开发机上的浏览器里的HTML页面和Javascript组成)，数据库(由插入到通用关系型数据库管理系统中的许多数据表格组成)，服务端应用程序。服务端应用程序处理HTTP请求，执行领域逻辑，从数据库中检索、更新数据，选择、填充将要发送到浏览器的HTTP视图。服务端应用程序是一个单一的逻辑可执行单体2。系统的任何改变都将牵涉到重新构建和部署服务端的一个新版本。
这样的单体服务器是构建这样一个系统最自然的方式。处理请求的所有逻辑都运行在一个单一进程中，允许你使用编程语言的基本特性将应用程序划分类、函数和命名空间。你认真的在开发机上运行测试应用程序，并使用部署管道来保证变更已被正确地测试并部署到生产环境中。该单体的水平扩展可以通过在负载均衡器后面运行多个实例来实现。
单体应用程序可以是成功的，但人们日益对他们感到挫败，尤其是随着更多的应用程序被部署在云上。变更周期被捆绑在一起 —— 即使只变更应用程序的一部分，也需要重新构建并部署整个单体。长此以往，通常将很难保持一个良好的模块架构，这使得很难变更只发生在需要变更的模块内。程序扩展要求进行整个应用程序的扩展而不是需要更多资源的应用程序部分的扩展。
图1: 单体和微服务
这些挫败导向了微服务架构风格：构建应用程序为服务套件。除了服务是可独立部署、可独立扩展的之外，每个服务都提供一个固定的模块边界。甚至允许不同的服务用不同的的语言开发，由不同的团队管理。
我们不会声称微服务风格是新颖的、创新的，其本质至少可以回溯到Unix的设计哲学。但我们的确认为没有足够的人仔细考虑微服务架构，并且如果使用它很多软件实现将会更好。
微服务架构的特征
我们无法给出微服务架构风格的一个正式定义，但我们可以尝试去描述我们看到的符合该架构的一些共性。就概述共性的任何定义来说，并非所有的微服务架构风格都有这些共性，但我们期望大多数微服务架构风格展现出大多数特性。虽然本文作者一直是这个相当松散的社区的活跃用户，我们的目的是试图描述我们工作中和我们知道的一些团队的相似努力中的所见所闻。特别是我们不会制定一些可遵守的定义。
通过服务组件化
只要我们一直从事软件行业，一个愿望就是通过把组件插在一起构建系统，如同我们看到的现实世界中事物的构造方式一样。在最近的二十年中，我们看到作为大多数语言平台一部分的公共库的大量汇编工作取得了很大的进展。
当谈到组件时，我们遭遇困难的定义：组件是什么。我们的定义是：组件是一个可独立替换和独立升级的软件单元。
微服务架构将使用库，但组件化软件的主要方式是分解成服务。我们把库定义为链接到程序并使用内存函数调用来调用的组件，而服务是一种进程外的组件，它通过web服务请求或rpc(远程过程调用)机制通信(这和很多面向对象程序中的服务对象的概念是不同的3。)
使用服务作为组件而不是使用库的一个主要原因是服务是可独立部署的。如果你有一个应用程序4是由单一进程里的多个库组成，任何一个组件的更改都导致必须重新部署整个应用程序。但如果应用程序可分解成多个服务，那么单个服务的变更只需要重新部署该服务即可。当然这也不是绝对的，一些变更将会改变服务接口导致一些协作，但一个好的微服务架构的目的是通过内聚服务边界和按合约演进机制来最小化这些协作。
使用服务作为组件的另一个结果是一个更加明确的组件接口。大多数语言没有一个好的机制来定义一个明确的发布接口。通常只有文档和规则来预防客户端打破组件的封装，这导致组件间过于紧耦合。服务通过明确的远程调用机制可以很容易的避免这些。
像这样使用服务确实有一些缺点，远程调用比进程内调用更昂贵，因此远程API被设计成粗粒度，这往往更不便于使用。如果你需要更改组件间的责任分配，当你跨进程边界时，这样的行为动作更难达成。
直观的估计，我们观察到服务与运行时进程一一映射，但这仅仅是直观的估计而已。一个服务可能由多进程组成，这些进程总是被一起开发和部署，比如只被这个服务使用的应用进程和数据库。
围绕业务能力组织
当想要把大型应用程序拆分成部件时，通常管理层聚焦在技术层面，导致UI团队、服务侧逻辑团队、数据库团队的划分。当团队按这些技术线路划分时，即使是简单的更改也会导致跨团队的时间和预算审批。一个聪明的团队将围绕这些优化，两害取其轻 - 只把业务逻辑强制放在它们会访问的应用程序中。换句话说，逻辑无处不在。这是Conway法则5在起作用的一个例子。
任何设计系统(广泛定义的)的组织将产生一种设计，他的结构就是该住址的通信结构。
-- Melvyn Conway 1967
图2: Conway法则在起作用
微服务采用不同的分割方法，划分成围绕业务能力组织的服务。这些服务采取该业务领域软件的宽栈实现，包括用户接口、持久化存储和任何外部协作。因此，团队都是跨职能的，包括开发需要的全方位技能：用户体验、数据库、项目管理。
图3: 团队边界增强的服务边界
www.comparethemarket.com是按这种方式组织的一个公司。跨职能团队负责创建和运营产品，产品被划分成若干个体服务，这些服务通过消息总线通信。
大型单体应用程序也总是可以围绕业务能力来模块化，虽然这不是常见的情况。当然，我们将敦促创建单体应用程序的大型团队将团队本身按业务线拆分。我们看到这种情况的主要问题是他们趋向于围绕太多的上下文进行组织。如果单体横跨了多个模块边界，对团队个体成员来说，很难把它们装进他们的短期记忆里。另外，我们看到模块化的路线需要大量的规则来强制实施。服务组件所要求的更加明确的分离，使得它更容易保持团队边界清晰。
侧边栏：微服务有多大？
虽然，“微服务”已成为这种架构风格的代称，这个名字确实会导致不幸的聚焦于服务的大小，并为“微”由什么组成争论不休。在与微服务实践者的对话中，我们发现有各种大小的服务。最大的服务报道遵循亚马逊两匹萨团队(也就是，整个团队吃两个披萨就吃饱了)的理念，这意味着团队不超过12个人。在更小的规模大小上，我们看到这样的安排，6人团队将支持6个服务。
这导致这样一个问题，在服务每12个人和服务每1个人的大小范围内，是否有足够打的不同使他们不能被集中在同一微服务标签下。目前，我们认为最好把它们组合在一起。但随着深入探索这种风格，我们一定有可能改变我们的看法。
是产品不是项目
我们看到大多数应用程序开发工作使用一个项目模式：目标是交付将要完成的一些软件。完成后的软件被交接给维护组织，然后它的构建团队就解散了。
微服务支持者倾向于避免这种模式，而是认为一个团队应该负责产品的整个生命周期。对此一个共同的启示是亚马逊的理念 “you build, you run it” ，开发团队负责软件的整个产品周期。这使开发者经常接触他们
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[153431]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
