乐趣区

关于云原生:系列文章｜云原生时代下微服务架构进阶之路微服务简介

jiezi

通过本篇文章您能够理解到以下内容:

  • 微服务架构的由来、历史
  • 微服务架构相比传统巨石利用的劣势
  • 微服务拆分准则概述

微服务架构的由来、历史

从软件架构的发展趋势来看，大体能够整体分为四个阶段:

前三个阶段别离是 巨石利用、3-Tier 架构、SOA 架构:

  • 巨石利用，顾名思义是将所有的业务逻辑用一个工程进行示意。（在上一篇文章中咱们进行了具体的介绍）
  • 3-Tier 架构，一种软件设计的思维。不同于巨石利用的模式，它将整个业务利用进行了档次划分。总共分为三层，自上而下别离是表示层、业务逻辑层、数据拜访层。另一方面，这种档次的辨别也体现了“高内聚低耦合”的思维。
  • SOA 架构，一种软件设计的思维，依照理论业务须要，拆分成粗粒度、松耦合的服务架构。

第四个阶段也就是咱们明天的配角，微服务架构。在谈到微服务架构的历史，咱们就不得不想到了以下几位巨匠:

  • Adrain Cockcroft，Netflix 架构师。主导了 Netflix 从 2009 年到 2016 年巨石利用到微服务架构演进的工作。并使得 Netflix 成为首批胜利从巨石利用迁徙到基于云的微服务架构的公司之一。
  • Fred George，在 2012 年的一次技术大会上，具体介绍了他和他的团队如何将百万级代码的传统利用进行革新拆分，并利用消息中间件（MQ）进行服务之间解耦的过程。
  • Martin Fowler，2014 年发表了一篇对于微服务架构的文章，这篇文章深刻全面的介绍了微服务架构。（链接）

另外对于云原生概念最早的提出者 Pivotal(曾经回归到了 VMware)对于微服务也给出了相干解释和阐明:

以上就是对于微服务架构历史的介绍，接下来让咱们看看微服务架构相比传统巨石利用的劣势又有哪些？

微服务架构相比传统巨石利用的劣势

在上一篇文章中咱们论述了传统巨石利用在我的项目晚期阶段的劣势，以及在随着我的项目一直倒退、扩充后显现出的弊病。那么绝对于传统巨石利用，微服务架构的劣势又有哪些呢?

  • 应用程序扩展性（相比传统巨石利用架构，微服务架构下，每个微服务具备自主运行的能力，这使得增加、删除、更新、扩大单个具体服务变得绝对容易。这种扭转并不会影响到其余服务）。
  • Two-Pizza 团队（每个微服务的所有权调配给一个小团队，团队与团队之间严密单干。从而大大提高了工作效率，也使得团队易于治理）。
  • 数据安全性（在微服务架构中，每一个服务具备本人独立的数据。当微服务之间建设数据连贯时，信息安全就会成为一个问题。侥幸的是，大多数通信应用的是平安 API。平安的 API 通过确保只有通过专门受权的应用程序、用户和服务器能力拜访数据，从而保障了数据的安全性）。
  • 疾速迭代、交付、验证（微服务最重要的劣势是灵活性，可能疾速迭代一个小的、集中的性能，并看到后果。因为企业能够疾速开发和部署新性能，用户能够在几周内看到他们的反馈，而不是几个月或几年。这大大促成了用户、开发人员和工程师之间的合作）。
  • 技术多样化（不同的团队能够应用不同的编程语言以及技术来实现他们的服务。服务与服务之间通过申明式的 API 进行交互，大大增加了技术的灵活性）。
  • 容错性（在微服务架构中，一个服务的故障不太可能对其余服务产生太大的影响，因为服务与服务之间是彼此独立运行的。然而大型散布式微服务体系结构往往具备许多依赖关系，因而须要防止的是当某个服务呈现故障，因为依赖关系所导致的其余服务不可用的状况，即容错性）。

微服务拆分准则概述

通过下面一章节的介绍，置信咱们分明的理解了微服务架构的劣势。当某一个新业务需要到来或者说对现有老旧的巨石利用进行革新时，咱们是否能够间接通过某种曾经选定的技术框架，就可能进行业务开发了呢? 答案是否定的。相比技术框架的确定以及具体的开发工作，更前置一步须要咱们进行解决的就是微服务的拆分。

这里能够把它归结为“三步走”形式：

  • 第一步（微服务拆分）此步骤能够分为两种状况。第一种状况即新的业务从 0 到 1 的构建。第二种状况即对已有的“巨石”利用进行革新，革新成微服务架构。
  • 第二步（技术选型）此步骤绝对比拟好了解，依据不同的业务模块的特点以及须要，能够应用不同的技术框架。这里不同于巨石利用，因为每一个微服务是独立开发、部署的，所以在技术选型下面会更加灵便多样化。例如针对 JAVA 技术栈，咱们能够使 Spring 全家桶，在曾经拆分好微服务的前提下，帮忙咱们从技术框架的角度疾速搭建微服务架构。
  • 第三步（业务开发）相干的开发人员依据业务需要，在相应技术框架的根底上进行业务的开发、测试、部署等操作。

从下面的介绍不难看出，微服务拆分在整个流程中是尤为重要的，然而只有谈到微服务拆分，置信大家都会据说一个名词，它就是 Domain Driven Design（畛域驱动设计，简称 DDD）。Domain Driven Design 起源于 Eric Evans 发表的书籍《DOMAIN-DRIVEN DESIGN TACKLING COMPLEXITY IN THE HEART OF SOFTWARE》（中文译名《畛域驱动设计—软件外围复杂性应答之道》。在此书中的一些概念，例如畛域、限界上下文等概念和微服务提倡的高内聚、低耦合有着完满的符合，进而越来越多的人把 Domain Driven Design 作为微服务拆分的一种领导准则。

如上图所示，咱们能够看到蕴含了泛滥概念，想要了解把握这些概念并做到灵活运用并不是一件容易的事件，同时 Domain Driven Design 是一种软件系统设计和开发的方法论，是一种指导思想。如何依据这种指导思想并联合无效的剖析工具进行理论落地，成为了大家广泛关注的问题。

那么作为云原生概念的提出者 Pivotal（VMware）在微服务拆分上的最佳实际是什么? 最佳实际过程中又会联合应用哪些工具?

在下期的文章中会持续和大家进行交换分享，敬请期待! 如您有任何倡议，欢送随时分割咱们!

参考链接:

  1. https://martinfowler.com/arti…
  2. https://tanzu.vmware.com/micr…

起源|公众号：VMwareTanzu 云原生

退出移动版