标签归档:架构

您应该学习微服务的十大理由

学习微服务的十大理由

始终关注新技术,语言和框架,以彻底改变您的组织。如果你仍然在你的立方体中粘贴你的整体框架中的代码,那么你可能生活在过去,你有一个小应用程序和很少的员工来处理它。现在情况发生了变化!你需要采取领先一步,并与革命性的技术在那里走路  微服务  是领导人之一。 

想知道微服务在2018年的最热门技术中的地位吗?了解Edureka的技能报告 !!

您是否正在寻找最佳理由来投入时间学习微服务以期成为架构师并使用它们来开发应用程序? 

以下是我学习微服务的十大理由:

  1. 高薪工作
  2. 使用最少的资源,降低拥有成本
  3. 促进最佳大数据实践
  4. 降低风险
  5. 提供粒度缩放
  6. 提供高质量的代码
  7. 提供跨团队协调
  8. 灵活地使用各种工具来完成所需的任务
  9. 提供持续交付
  10. 易于构建和维护应用程序

学习微服务的十大理由| Edureka

现在,让我帮助您更详细地了解这些内容。

10.易于构建和维护应用程序

当开发人员构建的产品变得稳定并且在市场上供客户使用时,开发人员团队主要分为以下活动。

  • 实现新功能
  • 修复错误
  • 更改现有功能

在这种情况下,如果产品基于单一框架,则代码库的每个更改都必须通过构建,维护和部署的所有阶段。

所以在这种情况下,微服务就像一个救世主!

易于构建和维护 - 学习微服务的十大理由 - Edureka

微服务解决了基于组织的问题,使调试和测试应用程序变得容易。在此框架的帮助下,持续交付,测试过程和提供无差错应用程序的能力大大提高。

9.提供持续交付

与专用团队为每个离散功能(如处理数据库,维护服务器端逻辑)工作的单片应用程序不同,微服务使用持续交付模型来处理应用程序的整个生命周期。

开发人员,操作人员,测试团队同时在单个服务上执行诸如构建,测试和调试之类的活动。

持续交付 - 学习微服务的十大理由 - Edureka

这种开发方法使代码能够不断开发,测试和部署。

因此,每次进行更改时都不必重新编写代码,只需从现有库中使用它即可!

8.灵活地使用各种工具完成所需任务

微服务架构鼓励使用最合适的技术来满足服务的特定需求。每项服务都可以自由使用自己的语言,框架或辅助服务。即使使用这种不同的框架,服务仍然可以与应用程序中的其他服务轻松通信。

混合技术 - 学习微服务的十大理由 - Edureka

7.提供跨团队协调

跨团队协调 - 学习微服务的十大理由 - Edureka

传统的面向服务的体系结构(SOA)涉及重量级的进程间通信协议。

但是,微服务,遵循分散化和解耦服务的概念,以便它们作为独立的实体。因此,在微服务架构中,每个团队处理各种实体,然后相互通信以处理不同的功能。

6.提供高质量的代码

遵循微服务的体系结构,完整的框架被模块化为离散组件。这有助于应用程序开发团队一次专注于一项特定的工作。因此,这反过来简化了整个编码和测试过程。

良好的质量准则 - 学习微服务的十大理由 - Edureka

5.提供粒度缩放

如果你谈论可扩展性,那么微服务就会胜过许多其他架构选择。

由于每个服务都是框架中的单独组件,因此您无需扩展整个应用程序即可扩展单个功能或服务。可以在多个服务器上部署关键业务服务,以提高可用性和性能,而不会影响其他服务的性能。

粒度缩放 - 学习微服务的十大理由 - Edureka

因此,微服务可以轻松识别扩展瓶颈,然后在每个微服务级别解决这些瓶颈。

4.降低风险

每个服务都是微服务框架中的一个独立实体,这允许本地化更改,更高的质量信任度和端到端回归方案。

降低风险 - 学习微服务的十大理由 - Edureka

因此,即使应用程序的一个服务或组件出现故障,整个应用程序也不会停止运行。相反,只有特定的服务或组件需要由开发人员重建。 

因此,这可以降低业务应用程序完全崩溃的风险!

3.促进大数据实践

微服务拥有其私有数据库来收集,摄取,处理和交付数据以实现其各自的业务功能。

大数据源 - Edureka因此,您可以说微服务与数据管道架构协作,以协调大数据收集,提取,处理和交付的方式,以微服务的形式处理小任务。

2.使用最少的资源,降低拥有成本

多个团队致力于独立服务,以便轻松部署。这种提高的微服务效率降低了基础架构成本,最大限度地减少了停机时间,优化了资源并使代码可重用。因此,在这些服务的帮助下,您不必在大型机器上运行,但基本机器将为您服务。

通过降低TCO提高投资回报率 - 学习微服务的十大理由 - Edureka

1.高薪工作

据Indeed.com称,“微服务”的平均工资范围从软件工程师每年约97,994美元到高级软件工程师每年116,027美元不等。 不仅在个人层面,而且许多超级增长公司,如Netflix,eBay,PayPal,Twitter,亚马逊在其结构中使用微服务。

我希望我的博客“学习微服务的十大理由”对你来说很重要。 

虽然它仍然处于起步阶段,如果您对这种架构很感兴趣,并且想要进行结构化学习,那么请查看我们的微服务  架构培训  ,该培训包括讲师指导的现场培训和现实生活项目经验。此培训将帮助您深入了解微服务,帮助您掌握主题。

微服务架构 – 学习,构建和部署微服务

微服务架构:

从我之前的博客中,您必须对微服务架构有基本的了解。 但是,作为一名拥有微服务认证专业知识的专业人士,需要的不仅仅是基础知识。 在本博客中,您将深入了解架构概念并使用UBER案例研究来实现它们。

在本博客中,您将了解以下内容:

  • 微服务架构的定义
  • 微服务架构的关键概念
  • 微服务架构的优缺点
  • UBER – 案例研究

您可以参考  什么是微服务,以了解微服务的基本原理和优点。

如果我给你微服务的定义,那将是公平的。

微服务的定义

因此,没有适当定义微服务又称微服务架构,但可以说它是一个由执行不同操作的小型,可单独部署的服务组成的框架。

微服务专注于单个业务域,可以作为完全独立的可部署服务实现,并在不同的技术堆栈上实现它们。

单片架构和微服务之间的差异 - 微服务架构 - Edureka

图1:   单片和微服务架构之间的差异 – 微服务架构

请参阅上图以了解单片和微服务架构之间的区别。为了更好地理解两种架构之间的差异,您可以参考我之前的博客  What Is Microservices

为了让您更好地理解,让我告诉您微服务架构的一些关键概念。

微服务架构的关键概念

在使用微服务开始构建自己的应用程序之前,您需要清楚应用程序的范围和功能。

以下是在讨论微服务时应遵循的一些指导原则。

设计微服务时的指南

  • 作为开发人员,当您决定构建一个单独的域应用程序并明确其功能时。
  • 您设计的每个微服务应仅集中于应用程序的一项服务。
  • 确保您已设计应用程序,使每个服务都可单独部署。
  • 确保微服务之间的通信是通过无状态服务器完成的。
  • 每个服务都可以进一步重构为更小的服务,拥有自己的微服务。

现在,您在设计微服务时已经阅读了基本指南,让我们了解微服务的架构。 

微服务架构如何工作?

典型的微服务架构(MSA)应包含以下组件:

  1. 客户端
  2. 身份提供者
  3. API网关
  4. 消息格式
  5. 数据库
  6. 静态内容
  7.  管理
  8. 服务发现

请参考下图。

微服务架构 - 微服务建筑学 - Edureka

图2:微服务 架构 – 微服务架构

我知道架构看起来有点复杂,但让 为你简化一下。

1.客户

该体系结构从不同类型的客户端开始,从尝试执行各种管理功能的不同设备(如搜索,构建,配置等)开始。

2.身份提供者

然后,来自客户端的这些请求在身份提供者上传递,身份提供者验证客户端的请求并将请求传递给API网关。然后通过定义良好的API网关将请求传递给内部服务。

3. API网关

由于客户端不直接调用服务,因此API网关充当客户端将请求转发到适当微服务的入口点。

使用API网关的优点包括:

  • 所有服务都可以在客户不知情的情况下进行更新。
  • 服务还可以使用非Web友好的消息传递协议。
  • API网关可以执行交叉功能,例如提供安全性,负载平衡等。

在接收到客户端的请求之后,内部体系结构由微服务组成,这些微服务通过消息相互通信以处理客户端请求。

4.消息格式

他们通过两种类型的消息进行通信:

  • 同步消息:  在客户端等待服务响应的情况下,微服务通常倾向于使用REST(Representational State Transfer),因为它依赖于无状态,客户端服务器和HTTP协议使用该协议,因为它是分布式环境,每个功能都用资源来表示以执行操作
  • 异步消息:在客户端不等待服务响应的情况下,微服务通常倾向于使用AMQP,STOMP,MQTT等协议这些协议用于此类通信,因为定义了消息的性质,并且这些消息必须在实现之间可互操作。

您可能会想到的下一个问题是使用微服务的应用程序如何处理他们的数据?

微服务架构培训

5.数据处理

好吧,每个微服务都拥有一个私有数据库来捕获他们的数据并实现相应的业务功能。此外,微服务的数据库仅通过其服务API进行更新。请参考下图:

每个微服务中的数据库表示 - 微服务架构 - Edureka494-02图3:   处理数据的微服务的表示 – 微服务架构

微服务提供的服务被转发到任何支持不同技术堆栈的进程间通信的远程服务。

6.静态内容

在微服务自身通信之后,他们将静态内容部署到基于云的存储服务,该服务可以通过内容交付网络(CDN)将它们直接传递给客户端  

除了上述组件外,还有一些其他组件出现在典型的微服务架构中:

7.管理

该组件负责平衡节点上的服务和识别故障。

8.服务发现

充当微服务的指南,以查找它们之间的通信路由,因为它维护节点所在的服务列表。

订阅我们的YouTube频道以获取新的更新..!

现在,让我们来看看这个架构的优缺点,以便更好地理解何时使用这个架构。

微服务架构的优缺点

请参阅下表。

 

微服务架构的优点 微服务架构的缺点
自由使用不同的技术 增加故障排除挑战
每个微服务都侧重于单一业务能力 由于远程呼叫而增加延迟
支持单个可部署单元 增加了配置和其他操作的工作量
允许频繁的软件发布 难以保持交易安全
确保每项服务的安全性 艰难地跟踪各种服务边界的数据
并行开发和部署多个服务 很难在服务之间移动代码

通过比较UBER以前的架构和现在的架构,让我们更多地了解微服务。

优步案例研究

UBER的先前架构

像许多创业公司一样,UBER开始了它的旅程,采用单一的架构,为单个城市的单一产品而建。当时似乎已经清理了一个代码库,并解决了UBER的核心业务问题。然而,随着UBER开始在全球范围内扩展,他们在可扩展性和持续集成方面严格面临各种问题。

UBER整体建筑学 - 微服务建筑学 - Edureka

  图4:   UBER的整体架构 – 微服务架构

上图描绘了UBER以前的架构。

  • 存在REST API,乘客和驾驶员连接。
  • 三个不同的适配器与其中的API一起使用,以执行诸如计费,付款,发送我们预订出租车时看到的电子邮件/消息等操作。
  • 用于存储所有数据的MySQL数据库。

因此,如果你注意到这里所有的功能,如乘客管理,计费,通知功能,支付,旅行管理和驾驶员管理都是在一个框架内组成的。

问题陈述

当UBER开始在全球范围内扩展时,这种框架引入了各种挑战。以下是一些突出的挑战

  • 必须一次又一次地重新构建,部署和测试所有功能以更新单个功能。
  • 修复错误在单个存储库中变得非常困难,因为开发人员不得不一次又一次地更改代码。
  • 通过在全球范围内引入新功能来同时扩展功能非常难以一起处理。

为了避免这些问题,UBER决定改变其架构,并关注其他超级增长型公司,如亚马逊,Netflix,Twitter和其他许多公司。因此,UBER决定将其单片架构分解为多个代码库,以形成微服务架构。

请参考下图查看UBER的微服务架构。

UBER微服务架构 - 微服务架构 - Edureka

图5:   UBER的微服务架构 – 微服务架构

  • 我们在这里观察到的主要变化是引入了所有驾驶员和乘客所连接的API网关。从API网关,所有内部点都连接起来,例如乘客管理,驾驶员管理,旅行管理等。
  • 这些单元是单独的可部署单元,执行单独的功能。

    • 例如:如果要更改计费微服务中的任何内容,则只需部署计费微服务,而不必部署其他微服务。
  • 所有功能现在都是单独缩放的,即每个功能之间的相互依赖性已被删除。

    • 例如,我们都知道搜索出租车的人数比实际预订出租车和付款的人数要多得多。这使我们得出一个推论,即在客运管理微服务上工作的流程数量超过了支付工作流程的数量。

通过这种方式,UBER将架构从单片机转移到微服务中获益

https://www.edureka.co/blog/microservice-architecture/

10位技术领袖告诉你趟过的微服务那些坑和最佳实践

切换到微服务架构似乎很容易,但技术领导者往往低估了项目的复杂性,并犯下灾难性的错误。此文对来自以色列和美国等5个国家的技术领袖进行了13次采访。这篇文章很长,内容包括如下一些方面:

• 微服务是什么 • 微服务架构优劣势分析 • 微服务面临的挑战和应对解决方案 • 微服务落地要避开的坑 • 来自技术领导型企业的微服务架构最佳实践 • 如何选择微服务当中的技术栈? • 实用的技术建议 为什么转向微服务? 企业容易犯的最大错误是在没有明确目标的情况下,转向微服务架构。需要了解并有真正的理由表明为什么要这样做。

“人们盲目进入很多领域:Docker很酷,微服务很伟大!但它可能不适合你的体系构建,你需要了解为什么要这么做。” – 来自Steven McCord, ICX Media(一家企业营销视频制作众包平台 )创始人兼CTO。

如果你的系统工作正常,那有什么动力去改变它?

如果只是因为微服务被炒作,这并不意味着你需要跳入潮流。它不一定是企业软件的最佳技术选择。

“确定原因至关重要。”这是David Dawson,Steven McCord和Avi Cavale 所强调的。

“当客户要求我实施微服务时,我会问的第一个问题是,为什么?我正在寻找的答案是,“希望更快地改变系统”和“希望利用云技术”。微服务其实比建立单一的系统更昂贵和困难。微服务在数据模型中引入网络,可以随时进行任意分割,但也可能伴随数据丢失,让企业暴露在分布式计算的恐惧之中。“ – 系统架构师 David Dawson说道。 明确定义一个微服务

“我不一定选择微服务。我倾向中型服务,所以不是从单体架构转到上百种的微服务,而是与工程团队和业务保持一致的更大的服务。” – 来自 Daniel Ben-Zvi , SimilarWeb(网站和应用追踪分析公司) 研发副总裁。

如何做?一个围观案例研究

“我们通过查看哪些代码(如果更改的话)最终确定了指数测试案例,从而确定了一个微服务。我们的目标是减少对每次改变的测试次数。如果这是你的目标,那么微服务的定义就和”计费就是一个微服务”没有什么不同。”Shippable 联合创始人兼CEO Avi Cavale 说道。 微服务架构优劣势分析

微服务显著优势 可扩展性:分析小块的应用,看每块的要求,每部分可以分别伸缩应用程序的不同部分。

“另外一个好处是,可以在任何虚拟机之外扩展容器。容器可以放置在任何形式的配置中,应用程序具有完全的可移植性。“ – ICX Media 创始人兼CTO Steven McCord说道。

更简单的可维护性:不同的团队以不同方式独立处理不同的组件。

独立部署和配置:部署和配置每个服务时,不会影响其他服务。多个团队可以将多个结果投放到生产中,不会彼此干扰。

问题隔离:更容易隔离和监测问题。

易于招聘:寻找开发人员或第三方供应商时,只需培训他们系统的一部分。

清晰的责任:一个团队负责特定的微服务。

深厚的知识:团队从内到外了解相关知识。

多种编程语言:可以使用不同的编程语言,这取决于微服务的目的。

更易于监督和理解:将庞大的代码分割成更小的项目,利于团队更好地理解。

更容易开放组件:当边界和接口被明确定义时,向新的业务单元开放组件或现有功能更容易。

微服务劣势

部署和互操作性:这是首要问题。

编程语言太多:会限制代码的可重用性以及可维护性,并且维护更加复杂。

组件一起工作:要确保服务是以一种协同工作的方式组成。只考虑改变单一的端点,会打破旧版本的其他依赖服务。

与单体系统相比,更难以对整个系统进行集成测试。

架构必须从一开始就深思熟虑:如果服务之间的凝聚力过大,也会失去大部分优势。

加大通信力度:在服务之间的通信方面,需要进行投入。服务的通信之间容易发生故障。

难以监控整个系统:大量组件对监控来说,是噩梦。

花时间学习:使用微服务需要学习,这需要时间。

复杂性:越来越多的微服务使整个系统更加复杂,难以监控。

“所有这些东西都散在周围。如果没有很好的工程流程,企业最终获得一大堆东西,然而根本不会使用。” – Shippable联合创始人兼CEO Avi Cavale说道。

“在基于微服务的平台上调试生产问题是完全不同的操作。如果没有相应的监测,记录和跟踪设施,系统的复杂性会显著增加。这就像迷宫一样。工程实践和标准化至关重要。” – SimilarWeb研发副总裁 Daniel Ben-Zvi 说道。

“记录到一个地方有挑战性。Loggly,Splunk或Heroku等第三方日志聚合服务是非常好的解决方案,但价格非常高。根据我的经验,遥测特别集中的日志是最大的难题。必须考虑每个服务的详细程度。否则,企业可能要花费50-60%的成本进行记录。”-来自微软公司SRE工程师 Sonu Kumar。 微服务面临的挑战和解决方案

当转向微服务时,如下这些是技术领导者和开发团队面临的最大挑战。 • 挑战1:一次切换所有系统 • 挑战2:拆分系统 • 挑战3:组织认同 • 挑战4:团队

> 挑战1:一次切换所有系统

“从单体架构切换到微服务架构不是一次就可以完成的。如果企业有单体服务器,那么其周围可能被存储库,部署任务,监控和其他许多事情包围。一起更改并不容易。” – AdRoll软件工程师Brujo Benavides说道。

“如果一个公司从未有任何微服务经验,即使是新建,也会比想象的更难。” – LogMeIn DevOps工程师 Viktor Tusa 说道。

white_check_mark:可能的解决方案

“那时候我们做的是保留单体服务器,但是任何新的服务都是通过微服务来开发的。”(Brujo Benavides)

挑战2:拆分系统

“如果组件和服务聚集在一起,隔离起来相当具有挑战性。(Robert Aistleitner)。需要定义各个部分之间的交互和流程。如果没有很好的定义,系统会产生更多问题。”- StyleSage高级开发人员 Jose Alvarez 表示。

“将系统拆分成微服务有许多不同的规则,没有特定的模式,没人会告诉你,如何在应用程序中使用它。而且,没有两个相同的微服务”。 – Recart 首席架构师大卫·帕普说道。

white_check_mark:可能的解决方案

“把单体系统分解成微服务的唯一方法,是首先检查单体系统,看看它最“痛”在哪里。将这些部分拿出来并转化成微服务“。 – Emarsys工程副总裁Andras Fincza表示。

监控所有部分是如何工作的以及他们在做什么。监控过程中,可以很容易地发现和解决问题。(Jose Alvarez)

模块by模块渐进地分离单片系统是最好的方法。想一次做所有事情,一定会失败的。

监控工具提示: • New Relic • Datadog • Influxdb • Grafana

挑战3:组织的支持

“获得组织认同可能是最难的部分。” – 来自 Steven McCord ,ICX Media创始人兼CTO。

这不是一个技术决定。需要清楚说明微服务架构的好处,从而说服企业重新分配资源。在企业接受变革之前,这是一个漫长而乏味的过程,组织规模越大,决策的时间越长。

white_check_mark:可能的解决方案

说服组织改用微服务的最佳方式,是将非核心部分转换为微服务。通过这种方式,来展示微服务的优势。

挑战4:团队

“团队本身面临着最大的挑战,它需要不同的思考。” “开发人员必须花费更多时间来了解什么是端到端场景。他们需要熟悉这些技术,需要转换思维方式。”

“对于一个在端到端测试的世界中工作的人来说,突然把它分解成小块,是不舒服的,这更多是文化上的变化。”-Shippable 联合创始人兼CEO Avi Cavale说道。

white_check_mark:可能的解决方案

从非常小的可以真正受益的方面开始,并选择应用程序的非关键部分。获得一个小团队的支持,并将这部分转换为微服务。一方面来证明微服务的优势,另一方面逐步向企业扩展(Avi Cavale)。

微服务落地要避开的坑

“避免同时将整个系统切换到微服务。” – Emarsys工程副总裁 Andras Fincza 说道。

“你能犯的最大的错误就是,没有创建一个微服务架构变化可能带来的影响概览。在实际开始实施新方法之前,必须包括大量移动组件。“ – Usersnap工程副总裁Robert Aistleitner说道。

“单体架构很容易改变内部接口。只需重构代码,然后运行测试。使用微服务,API必须可靠,你不一定知道你所有的客户。如果没有API的话,会给未来带来许多麻烦。此外,确保有分布式跟踪系统。”-来自 Daniel Ben-Zvi ,Similar Web研发副总裁。

“不要在没有搞清楚平台和依赖关系的情况下,尝试切换到微服务。此外,也要避免认为微服务都不错,因为每一个微服务可以用不同的语言来编写是一个不好的做法。” – 来自 Viktor Tusa ,LogMeIn DevOps工程师 。

“处理数据至关重要。搞砸数据非常容易,但是很难恢复。数据迁移需要更多步骤。” – Emarsys工程副总裁Andras Fincza表示。

“在微服务之间共享数据是一个很大的禁忌。如果两个服务操纵相同的数据,将遇到一致性问题,并消除所有权。“ – Daniel Ben-Zvi&Varun Villait二者共同认为。

“把应用程序分解成太多太小的东西,或者强迫把系统转变成微服务,这不应该是微服务 – 仅仅是炒作”。- 来自 Doctusoft首席开发Csaba Kassai 的观点。 来自技术领导型企业的微服务架构最佳实践

创建微服务之间的隔离,可以根据需要快速更改它们。这通常需要在几个层面进行隔离:

运行时流程:这是最明显的,也是普遍采用的过程。以前只有一个流程,而现在有很多。这里的主要成本是采用某种形式的分布式计算,这很难做到。会导致采用容器化,事件架构,各种http管理方法,服务网格和断路器。

团队/文化:分离团队,给予自主权,意味着划分人与人之间的沟通。这往往会导致知识孤岛和工作重叠(解决选择性与资源效率的选择)。

数据:采用像微服务这样的分布式计算最大的影响是它影响企业的数据。以某种形式对数据进行划分,需要在系统级别重新整合,以给出“一个系统”的印象。这在伸缩方面有潜在好处,但也需要相比简单的单一数据架构方法的更多想法。(来自David Dawson) 如何选择微服务当中的技术栈?

这是不同意见开始碰撞的地方…

一方面,人们认为使用什么技术和编程语言并不重要。

“几乎所有的问题都可以用任何技术解决。人们花费太多时间寻找正确的技术,如果以迭代的方式来做,你就有时间思考,并看到它的实际应用。错误的决策也可以得到缓解。” – Andras Fincza ,Emarsys 工程副总裁表示。

“大多数现代语言(Python,Java,C#,Node / JavaScript)同样快速且可扩展。从这个角度来看,语言无关紧要。每种语言都有其优点和缺点。大部分时间,语言选择是根据个人的喜好,而不是技术参数。” -Andras Fincza , LogMeIn DevOps 工程师说道。

花费大量的时间来选择最好的技术是不值得的,因为差异很小。

“选择技术的重要性被高估了。如果运行成本很重要,那么就可以接受,对我们来说没那么重要。” – Andras Fincza , Emarsys 工程副总裁。

“如果是新建项目,选择程序员最了解的语言。如果不是,选择客户端上最佳覆盖业务系统的语言。” -Viktor Tusa , LogMeIn DevOps 工程师 。

“微服务的好处在于它被封装在一个微服务中,只需要给外部的接口来谈论这件事。只要有一个界面就够了。“ -Steven McCord , ICX Media创始人兼CTO 。

选择合适的技术不仅仅是技术问题,也是一个决策。如果选择一种具有10种不同编程语言的微服务架构,要确保团队能够处理该问题。

“我不推荐混合太多的编程语言,因为招聘会变得更加困难。而且,程序员的上下文切换会减慢开发速度。“ – Robert Aistleitner , Usersnap工程副总裁。

“必须有意识地选择想要建立的开发团队类型。如果想使用许多不同的编程语言,需要建立一个能够使用和学习不同编程语言的动态团队。“ – Steven McCord , ICX Media创始人兼CTO 。 实用的技术建议 “我强烈建议在Google云端平台中使用管理服务,如App Engine。这将肩负很大的负担。此外,选择语言/技术时/框架时,选择合适的针对特定微服务的使用情况是重要的,不要因为熟悉它,而强迫选它。” – Csaba Kassai ,Doctusoft 首席开发。

以下来自Brujo Benavides:

一些技术领导者乐于推荐一些技术,这些技术可以很好地适用于服务特定角色的微服务。在选择微服务技术时,建议考虑: • 可维护性 • 容错 • 可扩展性 • 架构成本 • 易于部署 Brujo团队的一些微服务框架/技术示例: 
• Scrapy for web crawling • Celery + RabbitMQ用于微服务通信 • NLTK + Tensorflow(以及其他一些)用于机器学习部分 • AWS服务 如何选择合适的技术/语言?

在为微服务选择编程语言/技术时,需要考虑很多事情。

其中最重要的就是看你的开发人员具备哪些能力,以及语言/技术背后有多大的支持(工具,社区……)。根据我的经验,公司倾向于根据其开发人员的能力选择一种编程语言。“ – Csaba Kassai , Doctusoft首席开发人员。

“使用技术背后有很多支持(资源和活跃的社区)。我推荐Ruby和JavaScript,可以得到很多支持,如果出问题,很多人都可以提供帮助。只要确定有很多人使用它,选择语言不应该是问题。如果团队不具备这些知识,可以依靠外部资源。“ – Varun Villait,Industry CEO。

“另一个因素可能是图书馆可以用来加速项目的语言。你理想的语言的某些东西可能图书馆没有,不得不自己发明,这是另外的时间流失。容错和可扩展性也是重要因素。如果从现在开始的几个月内,你不得不重新编写一些东西,因为最初的选择无法扩展,那不如放弃。这一切都归结到一个特定的团队情况,他们愿意进行投入。” – Greg Neiheisel , Astronomer联合创始人兼 CTO 。

Emarsys就是这样看待这个过程的:

在Emarsys,如果他们想应用一种新的编程语言,开发人员需要提供真实的,合乎逻辑的理由,并咨询主要开发人员。团队聚集在一起讨论技术的优缺点。

他们总是用不同的技术创造一个尖峰解决方案。这可以让他们试验一个给定技术的边界,看看它是否可以应用于给定的微服务。这对于发现技术的局限性是完美的。

“建议使用您的团队已经熟悉的语言。这样,他们可以工作更舒适,进展较快。” –来自 Andras Fincza, Emarsys 公司工程副总裁 。

这是他们在SimilarWeb上所做的:

作为一家大数据和分析公司,我们面临着非常大的挑战,这增加了选择错误技术的风险和影响。单线程框架(如NodeJS)虽然适用于网络绑定服务,但在处理实时密集型数据处理时不会扩展。

工程师通过平衡战术和战略需求,同时考虑技术和组织的约束条件,来确定使用哪种技术。企业正处于快速成长阶段吗?服务是否需要处理大量数据?是否希望将新技术添加到堆栈中,是因为相信它的生态系统,还是使用我们已经掌握的现有技术?想要试验吗?能找到对此充满激情的工程师吗?是否愿意长期致力于这项技术?技术的生态系统是一个主要因素。我们希望与开源社区合作,使用和贡献现有的框架,而不是重新发明。

定义明确的指导方针甚至是清单可以帮助促进健康的决策过程,缩小可能的技术选择范围,从而选择最适合的团队和产品方案。

David Dawson提出的选择建议:

1.从数据架构的角度来看,需要一些可以轻松地将数据同步到服务之间的网络,并保持一致的可用状态。有很多种方法,这正是微服务部署中所需要的。可以观察实现这些模式的各种框架和技术。

2.一旦确定了模式和方法,就可以使用可用的资源来分析。如果已经决定采用大量反应式编程的数据流方法,并且拥有Java开发人员,那么选择Spring,Spring Cloud Data Flow和Kafka并且部署到某种形式的Cloud Foundry上(如果可以得到它!)。

如果需要大量更重的数据转换,请带上Spark或Kafka Streams 来解决这个问题。如果有JavaScript 开发人员,那么这个问题是没有道理的。相反,你会希望在JS运行时(clojurescript等)采用一些功能语言,再次使用一些类似的反应式集成技术(比如Kafka),并从那里采取。

关键要点: • 不要强调完美的技术,采取迭代的实验方法。 • 每个微服务架构都是独一无二的; 所选择的技术要与系统需求保持一致。 • 太多不同的技术使招聘更加复杂。 结论: 切换到微服务架构时,有很多挑战。在将系统转换为微服务之前,请确定要实现这一目的的真实原因。优点和缺点的分析会是一个很大的帮助。首先考虑系统的特性,而并非仅仅改变那些伤害最大的系统部分。不建议从头开始使用微服务架构,因为从一开始就明确界定微服务的边界是困难的。

如果决定切换到微服务,请采取渐进式方法,并从系统中取出非关键的一小部分,来了解它是如何工作的。这也是获得更多微服务的好办法。

对微服务来说,没有最好的方式可以选择完美的技术。每个与技术有关的决定都受到团队当前知识的影响,也受到公司未来招聘计划的影响。在某些情况下,选择微服务技术更多的是一个招聘决定,这取决于将来要建立一个什么样的开发团队。

为了缩窄可能的技术范围,来自Emarsys 的Andras Fincza,SimilarWeb的 Daniel BenZvi和David Dawson提供的经验值得借鉴。

文章来源: https://www.tuicool.com/articles/zaMnIz3

http://blog.shurenyun.com/10wei-ji-zhu-ling-xiu-gao-su-ni-tang-guo-de-wei-fu-wu-na-xie-keng-he-zui-jia-shi-jian/

那些没说出口的研发之痛,做与不做微服务的几大理由

创建一种新的软件项目架构,来封装离散服务,对于全新的项目来说,这是非常简单的。但是,对于大多数软件开发者来说,谁又有大把的奢侈时间一直用在全新项目上呢?

大多数软件开发人员职责更多是维护或增加现有软件系统的功能。但是,如果问开发人员究竟是愿意构建全新的项目,还是维护一个现有的系统,那么支持新项目的呼声肯定会成为压倒性的声音。事实上,希望与新技术或新项目合作也是开发人员离职的原因之一。为什么呢?

1

识别问题容易,但修复很难

维护现有系统时,很容易识别架构的问题。为什么?因为基于良好的架构,系统很容易调整。

当需要去调整一个没有设计封装波动的已有系统时,架构的弱点就不言自明。即使是最小的表层变化也会给整个系统的其他部分带来复杂的涟漪:新的依赖看似要无止境地延续下去,通过臃肿的方法签名获得更多的参数,自动化测试的规模和复杂性爆炸,同时降低了实际效用。

这些问题是不是听起来很熟悉?你企业的架构是这样的吗?

如果答案是肯定的,那么你有一个单体架构。单体架构是大多数软件开发者遇到的最常见架构。

这个单体架构来自那些根本没有设计封装波动的系统,但是随着业务需求和时间的推移,变得越来越复杂。

那么用单体架构做什么呢?

每个人在单体架构中工作时都会感到痛苦,开发和业务人员也是如此。开发者讨厌臃肿的单体架构,因为开发的难度会随着新开发动作的增加而增加。一旦单体架构达到临界值,如何改变会成为一个真正可怕的命题。这会导致生产力和团队士气下降,业务受到影响。企业需要快速行动,单体架构却会随着时间的推移而变得越来越慢。

许多开发人员都希望把已有的架构丢掉,重新开始,但是这种想法无法和业务一起成长。“最好的软件是目前就让企业赚钱的软件,无论设想中的新版本多么伟大!”

所以新的计划不能完全抛弃旧有的单体架构,业务要继续,但不会再增加单体架构的复杂度。

微服务?

微服务是一个流行的词汇,它模糊地表达了一个面向服务的架构,其中包含许多小的离散服务。

从表面上看,微服务似乎是单体架构的对立面(每个人都讨厌单体架构),许多微服务通过提出新的特性请求,并以独立服务的形式出现。这里的问题是:当单体架构封装所有系统的波动性,解耦的独立服务并不能使企业免于任何波动。

以下是用微服务实现单个功能架构,它大概像这个样子:

单体应用变得小了一点,新功能清晰地从系统的其余部分解耦。这很好吗?

当下一个功能请求进入时会发生什么?

有两个功能,我们已经看到一个问题。第二个功能建立在第一个功能之上,所以不能完全隔离。

如果随着功能请求的进入,简单地创建新的微服务,而不是封装整个波动区域:

有改善吗?来看看原始单体应用旁边的微服务:

如果仔细观察,会发现,所有服务依赖线模糊在一起,这只是发明了一个更复杂的单体架构。

小小的改变在整个系统中仍然会带来复杂的涟漪。整个系统的行为改变将涉及到改变多个微服务。所有相同的问题再次出现,甚至可能更糟糕,这加剧了依赖关系难以追踪的事实,而且,精心策划的多服务部署比庞大的单体应用更加可怕。

什么地方出了错?

问题源于微服务本身不是架构。微服务就是一个简单的词,描述了作为独立服务运行的系统,而不是一个单体应用。软件架构的实际实践包括仔细规划,在哪里划分离散服务之间的界限,从而包含波动区域。当简单地拿出一个单体应用,作为独立服务来实施时,就没有必要来考虑整个系统的封装波动。

把系统看作一个整体,才能谈架构

因此,如果单体应用,功能驱动的微服务太小,该怎么做应对?

要知道想去的方向

要像从头开始创建一样,为整个系统设计理想的架构。

企业不能一下子从一个单体架构直接进入微服务架构,但是如果第一次启动的时候,不清楚想达成的方向,那么永远也不会到达那里。

给所有希望拆分现有单体应用的软件开发者提供一些建议,但实际情况是这个路线图对于每个系统都是独一无二的。

Tips

如果只是设计新的功能而忽略已有的单体应用,则无法创建出色的架构;

如果不考虑整个系统,单体应用就不能有效分解;

微服务只是一个流行词。更小并不总是更好。精心拆分服务边界很重要;

2

微服务与团队:康威定律

微服务架构是独特的,随着时间的推移仍然保持灵活性,在一个项目的组织架构中时时发生影响 。对于大多公司而言,这非常具有挑战性,因为它要求企业重新考虑组织模式。当准备开始微服务架构时,可以先问自己:“企业的组织能力是什么?“在早期,先决条件应该是预先准备会遇到的困难,并思考应对之策。

微服务与康威定律:企业需要与团队协同的架构

当涉及到组织团队和微服务,著名的康威定律经常被提到。这项定律,越来越被广泛地接受。

这一定律的缺陷在于,它更多是一种社会学规律,而不是纯粹的科学规律,事实上,它总是以实证、实例的方式,而不是纯粹的科学逻辑来论证。一般来说,社会学的结果很难证明,因为这些论证很大程度上基于假想中的思考和概念,只能通过更多的实例来加以验证。

“组织的系统设计…往往受限于组织架构的产品设计和通信的副本。”从这个规律,可以得出一些简单的结论:

如果想要特定的结构,需要一个与组织团队协同的架构。

如果经常改变架构,组织团队也需要经常修改。

这两个断言,对于康威定律的原则,有着深远的影响。首先是一个企业的适应能力,避免了野心家的倾向,对变革的抵制等等,也引发了机器取代人力的哲学思考。

基于以上结论,要上微服务架构的第一个问题是:“组织团队如何适应这种架构?” Netflix 和亚马逊的情况,当然是很正向的,但是否你的企业是否准备好了?其中重要的是,挖掘技巧和发现问题时的“刹车”措施来规避风险。

其中的技巧能迅速提升团队的能力。在创建一个功能时,负责功能实现的团队汇集了很多不同的技巧。当架构进入微服务模式时,将出现更多的协调性需求。

另一个窍门是开源技术的治理模式。开源项目由于其分散的结构,使它能够创建高度松耦合的软件,这是微服务架构的优点之一。它因此成为与其他团队的协作方式,并推动具有代码能力的小团队,在代码中实现变化。

但是,这个逻辑和组织变革在公司的接受度如何?这些技巧是否足够在全公司范围内协调、积累经验和知识?分散的组织构建松耦合的代码,但技术或功能性的知识和技能不可能极端的解耦。否则,这就像拆东墙补西墙,是在用拆掉的墙来构建松耦合的架构。

真正的僵局会出现在文化和管理风格上,这点在最近几年有了好转。

一个比较好的例子是Spotify的框架(虽然我们应该限制自己使用meta frameworks,原因不再赘述)。Spotify采用通过使用开源组件来架构功能和治理,使用这些工具在一定规模下实现了灵活性矩阵模型。矩阵式组织必须确保知晓不同人具备的知识或技能。

最近流行的新管理方法已初见影响,特别是在那些寻求实现微服务的团队组织中。

Holacracy管理模式:满足业务模式前提下,完成微服务最佳实践

上面谈到了企业文化、主体、和变革的阻力。第一种类型的管理,来源于 Holacracy 管理模式。

Holacracy分为自治和独立,并链接比自己更高的实体。这些圈子以闭环的形式,可以互相重叠,具有自组织而被上层管理的特殊性。每个圈子对于性质和组成的变化非常敏感。

可以想象,例如,底层圈子是微服务的开发队伍,而上一层是架构和产品负责人,最顶端是应用的客户业务线。这将让产品和架构负责人要能在满足业务需求的前提下,才能保证架构的最佳实践。

这种架构方式也是开发者、软件架构师的典型方式。所有可能来自不同或重叠的圈子组织。建立这种类型的组织是为了提高知识传输和构建架构的时间效率。

我们可能会认为,这种管理比较符合传统的层级组织。事实上,即使层次是扁平的,它仍然存在,可以限制其项目团队。总之,最好的方式就是简化人与人之间的链接。

原文链接:

1、Microservices and monoliths: getting service-oriented architectures just right

https://www.tuicool.com/articles/VBzUFfJ

2、Executive Insights on the Current and Future State of Microservices

https://www.tuicool.com/articles/RfuAJn2

http://blog.shurenyun.com/na-xie-mei-shuo-chu-kou-de-yan-fa-zhi-tong-zuo-yu-bu-zuo-wei-fu-wu-de-ji-da-li-you/