微服务的概念,什么是 微服务

微服务的概念,什么是 微服务详细介绍

本文目录一览： 什么是 微服务

架构这个东西，从一开始都是单体服务，当业务上来之后，机器扛不住，需要横向还有纵向去提升整个系统服务能力，业务逻辑也会开始复杂起来，混乱不堪。这时就可以考虑微服务，简单来书偶就是将模块分割开来，分割成单独的机器，这样可以提高单独模块的服务能力。
同样的道理，JNPF也有单体版本和微服务版本，我们需要观察业务是否需要用到微服务，而不是强行为了技术而技术。
微服务架构是一种方法，其中单个应用程序由许多松散耦合且可独立部署的较小服务组成。

微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。

这些服务通常

虽然关于微服务的大部分讨论都围绕架构定义和特征展开，但它们的价值可以通过相当简单的业务和组织优势来更普遍地理解：

微服务也可以通过它们 不是 什么来理解。

与微服务架构最常进行的两个比较是单体架构和面向服务的架构 (SOA)。

微服务和单体架构之间的区别在于，微服务由许多较小的、松散耦合的服务组成一个应用程序，而不是大型、紧密耦合的应用程序的单体方法

微服务和 SOA 之间的区别可能不太清楚。

虽然可以在微服务和 SOA 之间进行技术对比，尤其是围绕 企业服务总线 (ESB) 的角色，但更容易将差异视为 范围之一 。

SOA 是企业范围内的一项努力，旨在标准化 组织中 所有 Web 服务相互通信和集成的方式，而微服务架构是特定于应用程序的。

微服务可能至少与开发人员一样受高管和项目负责人的欢迎。

这是微服务更不寻常的特征之一，因为架构热情通常是为软件开发团队保留的。

原因是微服务更好地反映了许多业务领导者希望构建和运行他们的团队和开发流程的方式。

换句话说，微服务是一种架构模型，可以更好地促进所需的操作模型。

在IBM 最近对 1,200 多名开发人员和 IT 主管进行的一项调查中，87% 的微服务用户同意微服务的采用是值得的。

也许微服务最重要的一个特点是，由于服务更小并且可以独立部署，它不再需要国会的法案来更改一行代码或在应用程序中添加新功能。

微服务向组织承诺提供一种解毒剂，以解决与需要大量时间的小改动相关的内心挫败感。

它不需要博士学位。

在计算机科学中看到或理解一种更好地促进速度和敏捷性的方法的价值。

但速度并不是以这种方式设计服务的唯一价值。

一种常见的新兴组织模型是围绕业务问题、服务或产品将跨职能团队聚集在一起。

微服务模型完全符合这一趋势，因为它使组织能够围绕一个服务或一组服务创建小型、跨职能的团队，并让他们以敏捷的方式运行。

微服务的松散耦合还为应用程序建立了一定程度的故障隔离和更好的弹性。

服务的小规模，加上清晰的边界和沟通模式，使新团队成员更容易理解代码库并快速为其做出贡献——在速度和员工士气方面都有明显的好处。

在传统的 n 层架构模式中，应用程序通常共享一个公共堆栈，其中一个大型关系数据库支持整个应用程序。

这种方法有几个明显的缺点——其中最重要的是应用程序的每个组件都必须共享一个公共堆栈、数据模型和数据库，即使对于某些元素的工作有一个清晰、更好的工具。

它造成了糟糕的架构，并且对于那些不断意识到构建这些组件的更好、更有效的方法是可用的开发人员来说是令人沮丧的。

相比之下，在微服务模型中，组件是独立部署的，并通过 REST、事件流和消息代理的某种组合进行通信——因此每个单独服务的堆栈都可以针对该服务进行优化。

技术一直在变化，由多个较小的服务组成的应用程序更容易和更便宜地随着更理想的技术发展而变得可用。

使用微服务，可以单独部署单个服务，但也可以单独扩展它们。由此产生的好处是显而易见的：如果做得正确，微服务比单体应用程序需要更少的基础设施，因为它们只支持对需要它的组件进行精确扩展，而不是在单体应用程序的情况下对整个应用程序进行扩展。

微服务的显着优势伴随着重大挑战。

从单体架构到微服务意味着更多的管理复杂性——更多的服务，由更多的团队创建，部署在更多的地方。

一项服务中的问题可能会导致或由其他服务中的问题引起。

日志数据（用于监控和解决问题）更加庞大，并且在服务之间可能不一致。

新版本可能会导致向后兼容性问题。

应用程序涉及更多的网络连接，这意味着出现延迟和连接问题的机会更多。

DevOps 方法可以解决其中的许多问题，但 DevOps 的采用也有其自身的挑战。

然而，这些挑战并没有阻止非采用者采用微服务——或者采用者深化他们的微服务承诺。

新的 IBM 调查数据 显示，56% 的当前非用户可能或非常可能在未来两年内采用微服务，78% 的当前微服务用户可能会增加他们在微服务上投入的时间、金钱和精力

微服务架构通常被描述为针对 DevOps 和持续集成/持续交付 (CI/CD) 进行了优化，在可以频繁部署的小型服务的上下文中，原因很容易理解。

但另一种看待微服务和 DevOps 之间关系的方式是，微服务架构实际上 需要 DevOps 才能成功。

虽然单体应用程序具有本文前面讨论过的一系列缺点，但它们的好处是它不是一个具有多个移动部件和独立技术堆栈的复杂分布式系统。

相比之下，鉴于微服务带来的复杂性、移动部件和依赖项的大量增加，在部署、监控和生命周期自动化方面没有大量投资的情况下使用微服务是不明智的。

虽然几乎任何现代工具或语言都可以在微服务架构中使用，但有一些核心工具已成为微服务必不可少的边界定义：

微服务的关键要素之一是它通常非常小。

（没有任意数量的代码可以确定某物是否是微服务，但名称中的“微”就在那里。）

当Docker在 2013 年迎来现代容器时代时，它还引入了与微服务最密切相关的计算模型。

由于单个容器没有自己的操作系统的开销，它们比传统的虚拟机更小更轻，并且可以更快地启动和关闭，使其成为微服务架构中更小、更轻的服务的完美匹配.

随着服务和容器的激增，编排和管理大量容器很快成为关键挑战之一。

Kubernetes是一个开源容器编排平台，已成为最受欢迎的编排解决方案之一，因为它做得非常好。

微服务通常通过 API 进行通信，尤其是在首次建立状态时。

虽然客户端和服务确实可以直接相互通信，但 API 网关通常是一个有用的中间层，尤其是当应用程序中的服务数量随着时间的推移而增长时。

API 网关通过路由请求、跨多个服务扇出请求以及提供额外的安全性和身份验证来充当客户端的反向代理。

有多种技术可用于实现 API 网关，包括 API 管理平台，但如果使用容器和 Kubernetes 实现微服务架构，则网关通常使用 Ingress 或最近的Istio 来实现。

虽然最佳实践可能是设计无状态服务，但状态仍然存在，服务需要了解它。

虽然 API 调用通常是为给定服务初始建立状态的有效方式，但它并不是保持最新状态的特别有效方式。

不断的轮询，“我们到了吗？” 保持服务最新的方法根本不切实际。

相反，有必要将建立状态的 API 调用与消息传递或事件流结合起来，以便服务可以广播状态的变化，而其他相关方可以监听这些变化并进行相应的调整。

这项工作可能最适合通用消息代理，但在某些情况下，事件流平台（例如Apache Kafka）可能更适合。

通过将微服务与事件驱动架构相结合，开发人员可以构建分布式、高度可扩展、容错和可扩展的系统，可以实时消费和处理大量事件或信息。

无服务器架构将一些核心云和微服务模式得出其合乎逻辑的结论。

在无服务器的情况下，执行单元不仅仅是一个小服务，而是一个函数，它通常可以只是几行代码。

将无服务器功能与微服务分开的界限很模糊，但通常认为功能比微服务还要小。

无服务器架构和功能即服务 (FaaS)平台与微服务的相似之处在于，它们都对创建更小的部署单元和根据需求精确扩展感兴趣。

微服务不一定与云计算完全相关，但它们如此频繁地结合在一起有几个重要原因——这些原因超越了微服务成为新应用程序的流行架构风格以及云成为新应用程序的流行托管目的地的原因。

微服务架构的主要优势之一是与单独部署和扩展组件相关的利用率和成本优势。

虽然这些优势在一定程度上仍然存在于本地基础设施中，但小型、独立可扩展的组件与按需、按使用付费的基础设施相结合是可以找到真正成本优化的地方。

其次，也许更重要的是，微服务的另一个主要好处是每个单独的组件都可以采用最适合其特定工作的堆栈。

当您自己管理堆栈扩散时，可能会导致严重的复杂性和开销，但是将支持堆栈作为云服务使用可以大大减少管理挑战。

换句话说，虽然推出自己的微服务基础设施并非不可能，但不可取，尤其是刚开始时。

在微服务架构中，有许多常见且有用的设计、通信和集成模式有助于解决一些更常见的挑战和机遇，包括：

例如，在桌面上使用的应用程序将具有与移动设备不同的屏幕尺寸、显示和性能限制。

BFF 模式允许开发人员使用该界面的最佳选项为每个用户界面创建和支持一种后端类型，而不是尝试支持适用于任何界面但可能会对前端性能产生负面影响的通用后端。

例如，在电子商务网站上，产品对象可能通过产品名称、类型和价格来区分。

聚合是应被视为一个单元的相关实体的集合。

因此，对于电子商务网站，订单将是买家订购的产品（实体）的集合（集合）。

这些模式用于以有意义的方式对数据进行分类。

在微服务架构中，服务实例会因伸缩、升级、服务故障甚至服务终止而动态变化。

这些模式提供了发现机制来应对这种短暂性。

负载平衡可以通过使用 健康 检查和服务故障作为重新平衡流量的触发器来使用服务发现模式。

适配器模式的目的是帮助翻译不兼容的类或对象之间的关系。

依赖第三方 API 的应用程序可能需要使用适配器模式来确保应用程序和 API 可以通信。

这个色彩缤纷的名字指的是藤蔓（微服务）如何随着时间的推移慢慢地超越并扼杀一棵树（单体应用程序）。

虽然有很多模式可以很好地完成微服务，但同样数量的模式可以很快让任何开发团队陷入困境。

其中一些——改写为微服务“不要”——如下：

一旦应用程序变得太大且难以轻松更新和维护，微服务是一种管理复杂性的方法。

只有当您感觉到单体架构的痛苦和复杂性开始蔓延时，才值得考虑如何将该应用程序重构为更小的服务。

在你感受到那种痛苦之前，你甚至没有真正拥有需要重构的单体。

尝试在没有 a) 适当的部署和监控自动化或 b) 托管云服务来支持您现在庞大的异构基础设施的情况下进行微服务，会带来很多不必要的麻烦。

省去你自己的麻烦，这样你就可以把时间花在担心状态上。

最好倾向于更大的服务，然后只在它们开始开发微服务解决的特征时才将它们分开——即部署更改变得困难和缓慢，通用数据模型变得过于复杂，或者不同部分服务有不同的负载/规模要求。

微服务和 SOA 之间的区别在于，微服务项目通常涉及重构应用程序以便更易于管理，而 SOA 关注的是改变 IT 服务在企业范围内的工作方式。

一个演变成 SOA 项目的微服务项目可能会因自身的重量而崩溃。

你最好从一个你可以处理的速度开始，避免复杂性，并尽可能多地使用现成的工具。

什么是微服务

“Mesh App and Service Architecture”作为Gartner2016 十大战略技术趋势中之一，里面大量提到微服务的概念。微服务（Microservices）这个概念不是新概念，很多公司已经在实践了，例如Google、Netflix、Facebook、Twiter、Alibaba。微服务架构模式（Microservices Architecture Pattern）的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以很容易得局部改良。
微服务从去年以来一直受到众多开发者的热捧，已经看到有许多项目尝试使用微服务架构，结果很鼓舞人心。然而，在微服务架构带来可独立部署、高扩展与伸缩、自由选择开发语言、高效利用资源、故障隔离等优点，同时也因为服务多带来分布式事务、服务之间通信、监控、部署等新的问题。
提到微服务架构时，我们常常会做的一件事情，就是会拿来与单体架构进行比较，单体架构存在如下缺点：代码维护难度大，臃肿的部署，局限的弹性与扩展能力，阻碍团队与技术革新等等；微服务架构存在如下优点：代码维护简化，可独立部署，高扩展与伸缩，自由选择开发语言等优点。那么单体架构真的如此不堪一击吗？答案显然不是这样，下面我们来看Martin Fowler在其一篇文章里面给出关系图：
上面的图来自 Martin Fowler 的文章，揭示了生产率和复杂度的一个关系。在复杂度较小时采用单体应用（Monolith）的生产率更高，复杂度到了一定规模时，单体应用的生产率开始急剧下降，这时对其进行微服务化的拆分才是合算的。所以说脱离业务场景，空谈架构绝对是耍流氓。异常牛逼的架构设计，如果无法在业务场景中落地实施，也只是空谈。因此架构需要服务于业务，针对不同的业务场景架构设计也会不同，架构设计不必追求高大上，简而美的架构，若能满足业务发展需求，便是好架构。此外，好的架构不完全是设计出来的，随着业务量、请求量的增长，好的架构是演化而来的。微服务架构之所以得到广泛认可，源于对于业务多变性的不可预测，微服务架构能够不断的自演化，进而快速适应业务变化。但相对于单体架构且经过严格定义的大规模开发项目，微服务架构要求大家面对由众多小型服务所构成的复杂生态系统。
鉴于此，如果长期业务规划不需要微服务架构或者团队不具备实施微服务一些基本的条件，不建议各位盲目迈向微服务这一新兴架构领域，或者从试点入手，逐步在团队中推行微服务架构。

什么是微服务架构啊？

微服务架构（MSA）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。
微服务本身并没有一个严格的定义，不过从很多人的反馈来看，大家都达成了这样一个共识：微服务是一种简单的应用，大概有10到100行代码。我知道使用代码行数来比较实现其实很不靠谱，因此你能理解这个意思就行，不必过分拘泥于细节。不过有一点需要注意，那就是微服务通常都是很小的，甚至是微型的。这意味着你不会在大型框架上看到很多小服务，这是不切实际的。简单与轻量级是当今的主流。诸如Sinatra、Webbit、Finagle与Connect等小型框架在将你的代码包装到一个薄薄的通信层这方面做得刚刚好。
从物理角度来说，这些服务都很小，你可以在同一台机器上运行大量服务，不必担心内存或是资源等问题。重申一遍，基于大型框架的简单库将会取得最后的胜利，你会发现对第三方库的依赖越来越少。
微服务架构其实没有一个非常准确的定义，大概描述的是一个大型复杂软件应用系统由若干个微服务组成。系统中的各个微服务能被独立部署和扩展，每个微服务还能提供一个稳固的模块边界。各个微服务之间是松耦合的，微服务很小，专注于做好一件事情。微服务框架带了良好的技术异构性、弹性、扩展性，它的简化部署为持续交付提供了巨大推动力。但是它同时也带来一些挑战，比如分布式事务一致性，网络性能消耗等问题。所以选用的时候要结合实际业务考虑，若想深入学习的话建议使用些现成的一些大厂商开源的微服务框架开发试试手，用一用spring cloud、servicecomb，网上资料都很多，希望这个回答对你有帮助。
微服务（Microservices）这个概念不是新概念，很多公司已经在实践了，例如Google、Netflix、Facebook、Twiter、Alibaba、新智云。微服务架构模式（Microservices Architecture Pattern）的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以很容易得局部改良。 微服务从去年以来一直受到众多开发者的热捧，已经看到有许多项目尝试使用微服务架构，结果很鼓舞人心。然而，在微服务架构带来可独立部署、高扩展与伸缩、自由选择开发语言、高效利用资源、故障隔离等优点，同时也因为服务多带来分布式事务、服务之间通信、监控、部署等新的问题...
微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。
微服务是指开发一个单个 小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。
微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。
微服务架构的优点：
每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
微服务架构的缺点：
微服务架构可能带来过多的操作。
需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps)。
可能双倍的努力。
分布式系统可能复杂难以管理。
因为分布部署跟踪问题难。
当服务数量增加，管理复杂性增加。
微服务适合哪种情况：
当需要支持桌面，web，移动智能电视，可穿戴时都是可以的。
甚至将来可能不知道但需要支持的某种环境。

谈谈微服务架构是一个怎样的存在？

微服务是近些年被广泛提及的一个概念， 微服务架构可以理解为一个轻量级的服务治理方案， 也就是将系统的功能，通过服务的形式发布到服务器上，对服务进行组合调用，实现具体的功能，解决实际业务问题的架构风格。
微服务产生于单体应用的扩大化，随着信息化不断发展，企业对软件功能的要求越来越具体，也愈发的细致，如果通过应用程序来实现，必然是一个极其复杂而又痛苦的过程，由此诞生了微服务的概念。就是 将功能发布成服务，应用程序通过调用不同的服务来实现业务， 这种设计架构称之为微服务。
微服务架构的优点在于每个服务可以有独立的团队开发，服务之间互不干涉，保障了系统的稳定性。由于功能被拆分到更细的粒度，有效的降低了程序的复杂程度，对硬件的需求也随之降低，但是微服务也有一些不足，比如服务调用带来的系统复杂性，服务间的依赖关系也是难以管理的，如何构建合理的服务依赖是考验架构师能力的重要依据；最后，微服务架构的部署以及跟踪也是很难的。总之， 微服务架构有着自身的应用场景以及特点，了解哪些场景适合微服务比掌握微服务的具体技术更为重要， 适当的技术用在适当的场景，才能发挥合适的价值。

微服务架构是当前最流行的技术架构，主要组件有注册中心、网关、配置中心和各种微服务模块。架构灵活、易扩展、可动态扩容。
在微服务之前，系统架构经历很长时间的演变，简述如下：
1.无架构 页面逻辑和业务逻辑混在一起，甚至页面直接访问数据库。
优点：因为没有太多的访问路径转换，效率是最高的；
缺点：没有分层，逻辑混乱，维护难，扩展难。
2.MVC
架构 单系统，表现层、逻辑层、业务层分开，各层分工协作。
优点：逻辑清晰、分工明确、易维护。
缺点：系统集中部署，属于强耦合，某些业务模块出现异常时，会导致整个系统无法访问。
3.SOA架构 面向服务的架构，多个系统分布式部署，通过消息总线进行通讯。
优点：各个系统的业务相对独立，耦合低；
缺点：消息总线负担太重，中心化太重，接口缺乏规范。
4.微服务架构 一个系统，按照粒度规划，划分为很多的微服务，而每个微服务，对应一个具体的业务实现，并可拥有自己独立的数据库，整个就是微服务架构。
优点：如上，架构灵活、易扩展，在实际运营时，按需扩容，集群部署。各个微服务业务互不影响，耦合性低；
缺点：开发成本高，对部署有一定的专业性要求。

从技术而言，微服务已经是一个设计理念很成熟的架构，可满足不同层次，不同业务场景的需要，而且经过多个版本的迭代，该踩的坑也基本踩完，生态系统完整，开源组件选择多多，很有一统天下的趋势，值得尝试。

但，不要为了微服务而微服务，要根据自己实际的要求去做抉择和取舍。
比较，适合自己的，才是最好的！
微服务是近几年技术社群讨论很多的一种软件架构方式，可以说是SOA的现代版本、 时尚 版本。不过这次浪潮不是由大公司倡导的，而是由工程师们引领的。比如，它采用工程师们熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂贵的中间件。
那微服务为什么流行起来？按理说它们都是让软件更加模块化，使相互之间保持松耦合，从而优化系统架构。
国内流行起来的微服务架构——RestCloud RestCloud 为了保证服务不注册中心癿高可用性，服务不注册中心通过水平扩展癿能
力允许对服务不注册中心迚行集群配置，开在网关层做了服务癿注册癿数据缓存。
Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件中癿一部分，它基于 Netflix Eureka做了二次封装。主要负责完成微服务架极中的服务治理功能。

易用性 如果你目前使用SpringBoot开发API服务则无需修改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。
稳定性 RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据. 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。
易用性 如果你目前使用SpringBoot开发API服务则无需修改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。
稳定性 RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据. 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。
网站链接：http://www.restcloud.cn/restcloud/mycms/index.html
参考资料：https://blog.csdn.net/kezi/article/details/81276727

微服务应用在什么领域

软件开发领域。微服务是一种针对敏捷开发的软件设计形式，是软件开发领域的一个概念。业务功能的各个部分，由不同背景的小团队独立开发、部署和管理。微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。

微服务的优点

微服务是指提供单个业务功能的服务，从技术角度看就是一种小而独立的处理过程，类似流程概念，能够自行单独启动或销毁，拥有自己独立的数据库。
一个复杂软件架构是由很多这样小而独立运行（有自己的端口）微服务组成，这些独立处理组件之间通讯是通过与语言无关的API进行，简单协议有同步性质的RMI/RPC和 RESTful Web Services，异步的消息推送和Reactive方式。
这些模块化的方式能够使得公司将项目分解分散到多个开发团队，跨不同业务部门，提供非常充分的灵活性，帮助提高项目的生命周期，加快项目开发完成效率。
每个微服务组件都有自己分配的存储 内存和CPU资源，这就使得硬件利用更加易于优化和跟踪，特别是在基于云的Pass环境，开发团队可以使用他们喜欢的技术，任何语言都可以，只要确保微服务之间是可交互的，能够最终组合起最后的应用。
当管理复杂性会因为采取微服务架构而降低，通常更新其中一个微服务组件不会引起连锁反应，因为微服务之间是松耦合的。
目前使用微服务的企业有：Netflix Twitter Amazon Web Services (AWS), Google, eBay等。
因为有很多应用和服务部署在基于云主机的环境中，微服务架构将会严重依赖容器技术，容器隔离了微服务处理过程，将一个应用切分为一个个小的实例，这些容器中的小实例有自己的端口和虚拟化环境。
广泛使用的容器技术是Docker, 一种基于Linux的开源实现，由很多软件公司支持如 Canonical, Red Hat,和Parallels. PaaS服务支持包括Google App Engine, Red Hat Open Shift,和VMware的 Cloud Foundry,。

什么是microservice;案例

定义
在 Martin Fowler & James Lewis 的文章(参考[1])里给出了微服务架构的一个定义:
微服务架构即是采用一组小服务来构建应用的方法。
每个服务运行在独立的进程中，不同服务通过一些轻量级交互机制来通信， 例如 RPC、HTTP 等。
服务围绕业务能力来构建，并依赖自动部署机制来独立部署。
这个定义相对还是模糊，但还是勾勒出了微服务的一些关键概念：小，独立进程，自动化。
起源
从微服务的定义，我们感觉似曾相识。早在 1994 年 Mike Gancarz 曾提出了 9 条著名原则(参考[4])，其中前 4 条和微服务架构理念特别接近。微服务就像把 UNIX 哲学应用到了分布式系统（参考[3]）。
Small is beautiful.
Make each program do one thing well.
Build a prototype as soon as possible.
Choose portability over efficiency.
小即是美：小的服务代码少，bug 也少，易测试，易维护，也更容易不断迭代完善的精致进而美妙。
一个程序只做好一件事：一个服务也只需要做好一件好，专注才能做好。
尽可能早地创建原型：尽可能早的提供服务 API，建立服务契约，达成服务间沟通的一致性约定，至于实现和完善可以慢慢再做。
可移植性比效率更重要：服务间的轻量级交互协议在效率和可移植性二者间，首要依然考虑兼容性和移植性。
可见微服务其实不是凭空产生的，它自有其历史的渊源。而在微服务之前的十年，大家经常谈论的是一个叫 SOA（面向服务）的架构模式，它和微服务又是什么关系？在 Sam Newman 的《Building Microservices》（参考[2]）一书中，作者对 SOA 和 Micorservices 的区别给出了定义：
You should instead think of Microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.
你可以把微服务想成是 SOA 的一种实践方式，正如 XP 或 Scrum 是敏捷软件开发的实践方式。我对这个定义是认同的，面向服务架构（SOA）的概念已有十多年，它提出了一种架构设计思想， 但没有给出标准的参考实现，而早期企业软件业界自己摸索了一套实践方式 —— 企业服务总线（ESB）。 但历史证明 ESB 的实现方案甚至在传统企业软件行业也未取得成功，Martin Fowler 在文中说正是因为 ESB 当年搞砸了很多项目， 投入几百万美金，产出几乎为零，因此 SOA 这个概念也蒙上了不详的标签，所以当微服务架构出现时， 其拥护者开始拒绝使用包裹着失败阴影的 SOA 这个标签，而直接称其为微服务架构（Microservices Architecture Style）， 让人以为是一套全新的架构思想，但事实上它的本质依然是 SOA 的一种实践方式。
特征
一个按微服务架构理念构建的系统应该具备什么样的特征呢？Martin 在其文章（参考[1]）中做了详尽的阐述，我这里简单归纳下。
组件服务化
传统实现组件的方式是通过库（library），库是和应用一起运行在进程中，库的局部变化意味着整个应用的重新部署。 通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需重新部署对应的服务进程。
按业务能力组织服务
按业务能力组织服务的意思是服务提供的能力和业务功能对应，比如：订单服务和数据访问服务，前者反应了真实的订单相关业务，后者是一种技术抽象服务不反应真实的业务。所以按微服务架构理念来划分服务时，是不应该存在数据访问服务这样一个服务的。
Melvin Conway 在 1967 年观察到一个现象并总结出了一条著名的康威定律（参考[5]）:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
设计系统的组织，最终产生的设计等价于组织的沟通结构。传统开发方式中，我们将工程师按技能专长分层为前端层、中间层、数据层，前端对应的角色为 UI、页面构建师等，中间层对应的角色为后端业务开发工程师，数据层对应着 DBA 等角色。
事实上传统应用设计架构的分层结构正反应了不同角色的沟通结构。所以若要按微服务的方式来构建应用，也需要对应调整团队的组织架构。每个服务背后的小团队的组织是跨功能的，包含实现业务所需的全面的技能。
服务即产品
传统的应用开发都是基于项目模式的，开发团队根据一堆功能列表开发出一个软件应用并交付给客户后，该软件应用就进入维护模式，由另一个维护团队负责，开发团队的职责结束。 而微服务架构建议避免采用这种项目模式，更倾向于让开发团队负责整个产品的全部生命周期。Amazon 对此提出了一个观点：
You build it, you run it.
开发团队对软件在生产环境的运行负全部责任，让服务的开发者与服务的使用者（客户）形成每日的交流反馈，来自直接客户的反馈有助于开发者提升服务的品质。

如何快速搭建一个微服务架构

什么是微服务？
微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务的概念源于2014年3月Martin Fowler所写的文章“Microservices” martinfowler.com/articles/mi…
单体架构(Monolithic Architecture )
企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。
这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包

上图：单体架构
大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。
多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。
单体架构的应用一般有以下特点：
微服务架构（Microservices Architecture）
微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！

上图：微服务架构
微服务设计
那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：
微服务消息
在单体架构中，不同功能之间通信通过方法调用，或者跨语言通信。SOA降低了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务需要更轻量的机制。
同步消息 REST
同步消息就是客户端需要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每个功能代表了一个资源和对应的操作）
异步消息 – AMQP, STOMP, MQTT
异步消息就是客户端不需要一直等待服务应答，有应到后会得到通知。某些微服务需要用到异步消息，一般采用AMQP, STOMP, MQTT 这三种通讯协议
消息格式 – JSON, XML, Thrift, ProtoBuf, Avro
消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。如果需要二进制，通过用到Thrift, ProtoBuf, Avro。
服务约定 – 定义接口 – Swagger, RAML, Thrift IDL
如果把功能实现为服务，并发布，需要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂并且和SOAP紧耦合，不适合微服务。
REST设计的微服务，通常采用Swagger和RAML定义约定。
对于不是基于REST设计的微服务，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。
微服务集成 (服务间通信)
大部分微服务基于RPC、HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。
点对点方式
点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。

上图：通过点对点方式通信
很明显，在比较简单的微服务应用场景下，这种方式还可行，随着应用复杂度的提升，会变得越来越不可维护。这点有些类似SOA的ESB，尽量不采用点对点的集成方式。
API-网关方式
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

上图：通过API-网关暴露微服务
所有的业务接口通过API网关暴露，是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。\
采用网关方式有如下优势：
目前，API网关方式应该是微服务架构中应用最广泛的设计模式。
消息代理方式
微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。

上图：异步通信方式
通常异步的生产者/消费者模式，通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。
数据的去中心化
单体架构中，不同功能的服务模块都把数据存储在某个中心数据库中。

每个微服务有自己私有的数据库，其它微服务不能直接访问。单体架构，用一个数据库存储所有数据
微服务方式，多个服务之间的设计相互独立，数据也应该相互独立（比如，某个微服务的数据库结构定义方式改变，可能会中断其它服务）。因此，每个微服务都应该有自己的数据库。

每个微服务有自己私有的数据库，其它微服务不能直接访问。每个微服务有自己私有的数据库，其它微服务不能直接访问。
数据去中心话的核心要点：
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
微服务架构的优点：
微服务架构的缺点：
微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。
关于微服务架构的取舍

一分钟弄懂什么是分布式和微服务

简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同

微服务是啥？
这里不引用书本上的复杂概论了，简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。
微服务架构又是啥？
在做架构设计的时候，先做逻辑架构，再做物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器能否满足需求，如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里，如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。

那么分布式又是啥？
分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。
微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难