展开查看详情
2 .6 5 4 3 2 1 目 录 CONTENTS 微服务的诞生 具体应用 Monolith 微服务架构的优点与缺点 微服务的定义 微服务架构模式
4 . 微 服务架构（ Microservice Architect ）是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
5 .背景 微服务的诞生并非偶然。它是互联网 高速 发展 ，敏捷、精益、持续交付方法论的深入 人 心 ，虚拟化 技 术与 DevOps 文化 的 快速发 展 以及传统 单 块架构 无法 适 应 快速 变化等 多重 因素的 推 动下所 诞生 的 产物
7 .通常，要开发的服务 所对应的代码由多个项目所组成，各个项目会根据自身所提供功能的不同具有一个明确的边界 。
8 .在编译时，这些项目将被打包成为一个个 JAR 包，并最终合并在一起形成一个 WAR 包。接下来，我们需要将该 WAR 包上传到 Web 容器中，解压该 WAR 包，并重新启动服务器。
9 .在执行完这一系列操作之后，我们对服务的编译及部署就已经完成了
10 .这种将所有的代码及功能都包含在一个 WAR 包中的项目组织方式被称为 Monolith 。在项目较小的情况下，这种代码组织方式还是可以接受的：更改完代码后 ，编译器 编译代码，然后软件开发人员花费一分钟部署刚刚编译出来的 WAR 包以便测试自己刚刚所做的更改。但随着项目的逐渐变大，整个开发流程的时间也会变得很长：即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。
11 .如果应用的部署非常麻烦，那么为了对 自己 的 更改进行测试，软件开发人员还需要在 部署 前 进行大量的环境设置，进而使得软件开发 人员 的 工作变得繁杂而无趣 从上面的示意图中可以看到，在应用变大之后，软件开发人员花在编译及部署的时间明显增多，甚至超过了他对代码进行更改并测试的时间，效率已经变得十分低下。
12 .在变得越来越大的同时，我们的应用所使用的技术也会变得越来越多。这些技术有些是不兼容的，就比如在一个项目中大范围地混合使用 C++ 和 Java 几乎是不可能的事情。在这种情况下，我们就需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能 。 除此之外，由于按照 Monolith 组织的代码将只产生一个包含了所有功能的 WAR 包，因此在对服务的容量进行扩展的时候，我们只能选择重复地部署这些 WAR 包来扩展服务能力，而不是仅仅扩展出现系统瓶颈的组成
13 .但是这种扩展方式极大地浪费了资源。就以上图所展示的情况为例：在一个服务中，某个组成的负载已经达到了 90% ，也就是到了不得不对服务能力进行扩容的时候了。而同一服务的其它三个组成的负载还没有到其处理能力的 20% 。
14 .由于 Monolith 服务中的各个组成是打包在同一个 WAR 包中的，因此通过添加一个额外的服务实例虽然可以将需要扩容的组成的负载降低到了 45% ，但是也使得其它各组成的利用率更为低下 。
15 .可以说，所有的不便都是由于 Monolith 服务中一个 WAR 包包含了该服务的所有功能所导致的。而解决该问题的方法就是 Microservice 架构模式。
17 .实际上，从业界的讨论来看 , 微服务本身并没有一个严格的定义。不过， ThoughtWorks 的首席科学家，马丁 - 福勒先生对微服务的这段描述，似乎更加具体、贴切，通俗易懂：
18 .Microservice The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
19 .微服务架构 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 RESTful API ）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
20 .将功能分散到各个离散的服务中然后实现对方案的解耦。服务更原子，自治更小，然后高密度部署服务
22 .简单地说， Microservice 架构模式就是将整个 Web 应用组织为一系列小的 Web 服务。这些小的 Web 服务可以独立地编译及部署，并通过各自暴露的 API 接口相互通讯。它们彼此相互协作，作为一个整体为用户提供功能，却可以独立地进行扩容。
23 .以下图所示的 WikiPedia 服务架构为例 WikiPedia 包含了一系列服务，如数据访问服务 Databases ，搜索服务 Search 等。这些服务都包含了数量不等的服务实例，以确保能在不同负载的情况下为用户提供优质的服务。在用户的请求到达时，它们将协同工作，一起完成对用户请求的响应
24 .在使用 Microservice 架 构 模式的情况下，软件 开 发 人员可以通过编译并重新部署单个子服务的方式来验证自己的更改，而不再需要重新编译整个应用，从而节省了大量的时间。同时由于每个子服务是独立的，因此各个服务内部可以自行决定最为合适的实现技术，使得这些子服务的开发变得更为容易。最后如果当前系统的容量不够了，那么我们只需要找到成为系统瓶颈的子服务，并扩展该子服务的容量即可。
26 .优点 1 每个服务足够内聚，足够小，代码容易理解、开发效率提高 2 服务之间可以独立部署，微服务架构让持续部署成为可能 3 每个服务可以各自进行 x 扩展和 z 扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上 4 容易扩大开发团队，可以针对每个服务（ service ）组件开发团队 5 提高容错性（ fault isolation ），一个服务的内存泄露并不会让整个系统瘫痪 6 系统不会被长期限制在某个技术栈上
27 .缺点 1 开发人员要处理分布式系统的复杂性 ； 开发 人员要设计服务之间的通信机制， 对 于 需要多个后端服务的 user case ，要在 没有分布式 事务的情况下实现代码非常困难；涉及多个服务直接的自动化测试也具备相当的挑战性 服务管理的复杂性，在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹（ PS ：现在 docker 的出现适合解决这个问题） 2 应用微服务架构的时机如何把握？对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错 3
29 .目前国外使用微服务架构的知名厂商中 不乏 Amazon 、 Twitter 、 Netflix 等这样的科技巨头 ， 但是 国内在微服务领域实践这块，真正成功的案例屈指可数，好雨云平台强调应用一键部署，整个平台的核心正是基于微服务的架构去搭建，可以说，好雨云在微服务领域有着成功的经验和技术
热门城市
