都在说微服务,那么微服务的反模式和陷井是什么(二)

原创 2017年09月26日 09:53:04

都在说微服务,那么微服务的反模式和陷井是什么(一)
http://blog.csdn.net/u013970991/article/details/78079910

六、无因的开发者陷阱

名字来自詹姆斯·迪恩演的电影《无因的反叛》(Rebel Without a Cause),一个问题青年因为错误的原因做了错误的决定。

很多架构师和开发者在微服务的开发中权衡利弊, 比如服务粒度和运维工具,但是基于错误的原因,做了错误的决定。

6.1 做出错误的决定

图6-1说明了一种情况是通过测试发现服务划分的太细了,因此非常影响性能,主要是由于服务划分的太细导致增加了通信工作量也在一定程度上对稳定性造成一定影响。在这种情况下,开发人员或架构师决定将这些服务整合到一个更粗粒度的服务中,以解决性能和可靠性问题。

图6-1

这个方案看起来似乎合情合理,但是之后的布署、更改控制和测试都会受到影响。

再看图6-2,这种场景是左边的服务太粗了,影响了服务的测试和布署,于是进行了拆分,减少了每个服务的范围。

图6-2

通过以上二个场景我们可以看出,如果服务太细我们就需要考虑将服务合并,如果服务太粗,我们又会考虑将服务进行拆分。太细的话会增加通信成本和容易造成可靠性不稳定,太粗的话又容易导致不容易测试和上线布署,所以这就要看我们如何来权衡利弊。

6.2 了解业务驱动

了解业务驱动对于合理设计微服务至关重要,每一个架构师或者开发者都应该先回答以下三个问题:
* 我们为什么要设计微服务架构?
* 主要的业务驱动是什么?
* 最重要的架构特点是什么?

使用可布署、性能、健壮性和可扩展作为主要的架构特性,我们其实最先需要考虑的是如何利用业务来进行服务的整合和拆分。

场景一:迁移到微服务主要是想达到快速上线和布署

在这种场景下服务的可布署能力相对要大于性能、稳定性因素,所以要拆分服务的时候可以考虑稍微细粒度一些。

场景二:迁移到微服务主要是想提高系统的性能和健壮性

这种场景是从单一应用程序迁移到微服务架构的一个常见因素,很多公司都是业务驱动,那么就需要考虑服务的可靠性和健壮性,因此倾向于更粗粒度的服务,而不是细粒度的服务。

我经常使用的一种方式借助白板和团队成员一起讨论,如图6-3所示,每当有服务粒度的划分问题的时候,我们经常在白板上做草稿讨论清楚。

图6-3

七、赶潮流陷阱

你必须拥抱微服务,因为这是目前的趋势,而且其他人和公司目前都已经这么做了。

我们盲目的使用微服务,却还没有仔细分析业务需求、组织架构和技术环境,这就是随大流陷阱。

避免这个陷阱的方式充分理解微服务的好处和短处,俗话说,知己知彼,百战不殆。

7.1 微服务的优点和缺点

优点:

  • 发布:易于发布
  • 测试:易于测试
  • 改变控制:更容易的改变一个服务的功能
  • 模块
  • 规模可扩展

缺点:

  • Team组织改变
  • 性能
  • 可靠性降低
  • 运维难度加大
7.2 其他架构模型

微服务的架构很好,但是不是唯一的架构模式,比如下面还有一些其它的架构模式:

  • Service-Based Architecture
  • Service-Oriented Architecture
  • Layered Architecture
  • Microkernel Architecture
  • Space-Based Architecture
  • Event-Driven Architecture
  • Pipeline Architecture

当然你并不一定只使用唯一的一种架构模式,你可能在系统中混用这些架构模式。

下面有一些架构的参考资料:
Software Architecture Fundamentals: Understanding the Basics
Software Architecture Fundamentals: Beyond the Basics
Software Architecture Fundamentals: Service-Based Architecture
Software Architecture Patterns
Microservices vs. Service-Oriented Architecture

八、静态契约陷阱

在微服务的消费者和提供者之间提供了一种契约,契约主要包括输入和输出数据、以及操作的名称,契约通常是以XML、JSON或者JAVA对象等来表示。但是这些契约永远不会改变吗?

这里举个例子来说明因为服务契约版本控制而发生的问题:
假如你有一个服务是由三个不同的客户端访问(client1、client2和client3),这时client1想更改服务契约,你要检查client2和client3能否适应这个改变,并且client2和client3告诉我适应不了这个改变,需要数周时间才能调整完成。这时候我需要告诉client1,client2和client3需要数周时间才能适应调整完成,但是client1却不能等待这么长时间。

可以在你的服务契约中提供版本控制,实现向后兼容。现在我们可以根据client1的请求做一些灵活的控制,我们可以创建一个新版本的契约,比如v1.1,client2和client3依然使用v1版本,这样client1就可以立刻作为契约更改,而不必纠结于client2和client3需要适应调整的时间。

有两种实现方式:在header中加入版本号,或者在契约自身scheme中加入版本号。

8.1 header版本控制

契约版本的第一种办法是把版本号放在远程访问协议头,如图8-1所示,远程访问协议包括REST, SOAP, AMQP, JMS, MSMQ等等。

图8-1

例如在使用REST的时候,可以使用MIME类型来指定协议版本,如下代码:

POST /trade/buy
Accept: application/vnd.svc.trade.v2+json

通过在header的MIME类型中指定契约版本号,服务端就可以通过header的MINE类型解析得到相应的版本号。

8.2 Schema版本控制

第二种版本控制方式是在契约自身中进行,不需要在header中指定版本号,如图8-2所示。

图8-2

请先看如下json格式数据:

{
        "$schema": "http://json-schema.org/draft-04/schema#",
        "properties": {
          "version": {"type": "integer"},
          "acct": {"type": "number"},
          "cusip": {"type": "string"},
          "sedol": {"type": "string"},
          "shares": {"type": "number", "minimum": 100}
       },
        "required": ["version", "acct", "shares"]
}

该模式直接将版本号定义在契约的输入数据中,这种模式最大的优点是与协议无关,只与数据格式有关。

POST /trade/buy
    Accept: application/json
    { "version": "2",
      "acct": "12345",
      "sedol": "2046251",
      "shares": "1000" }

    String msg = createJSON(
      "version","2",
      "acct","12345",
      "sedol","2046251",
      "shares","1000")};
    jmsContext.createProducer().send(queue, msg);

这种方式也有一些不足就是每一次都需要对消息数据进行解析,提取出版本号进行校验,而且数据格式也有可能会改变也不太容易做到自动映射到JAVA对象中。

版权声明:本文为博主原创文章,未经博主允许不得转载。

小程聊微服务-基于dubbo的mock测试系统

一、说在前面 基于微服务或者SOA的自动化测试系统每个公司都有自己的特有的,我今天就主要介绍一下,我们研发的一套mock测试系统。 二、目前面临的问题 1、测试人员面临的测试问题 我公司目前用的是...
  • u013970991
  • u013970991
  • 2017年02月04日 14:10
  • 5779

从理论到实践落地「微服务

从理论到实践落地「微服务」 作者|程超编辑|小智若论近年来大热的技术名词,微服务必定有一席之地。对于微服务的阐述已有很多,但很多不过流于框架、架构介绍,恍若空中楼阁。这是一篇理论与实践结合谈微服务的...
  • u010412301
  • u010412301
  • 2017年10月10日 09:35
  • 4957

iTest微服务测试经验总结(第一版)

itest的们使用心得
  • breathelove
  • breathelove
  • 2017年01月19日 10:49
  • 136

微服务架构与实践学习笔记

摘要微服务,持续集成(Jenkins),构建(Maven,Gradle),部署(Docker),持续交付(Jenkins),日志聚合(ELK),运维(监控警告Zabbix) 本内容为学习(王磊 著)...
  • bobshute
  • bobshute
  • 2017年04月09日 15:39
  • 1323

Spring Cloud Netflix 微服务压力测试

对微服务的提供者和消费者组建的集合进行压力测试,以发现可能的问题和解决的方法。...
  • ClementAD
  • ClementAD
  • 2017年01月10日 17:26
  • 7106

微服务架构选型实践

背景随着公司一年多的成长,我们已经开发了数十个项目了,后台有 JAVA 的有 PHP 的,为了更好地提升开发与管理效率,各技术大牛小牛们时常进行激烈的 PK,碰撞出了许许多多爱的火花,比如其中之一:微...
  • t4i2b10X4c22nF6A
  • t4i2b10X4c22nF6A
  • 2018年01月12日 00:00
  • 435

微服务架构下的测试之道

作者:袁慎建,崇尚简约,热爱编程 && 运动健身 && 知识分享,擅长敏捷开发实践,持续集成 && 持续交付,关注代码整洁 && TDD,关注软件质量来自:sjyuan.cc1.系统架构的演变伴随着互...
  • g6U8W7p06dCO99fQ3
  • g6U8W7p06dCO99fQ3
  • 2018年02月01日 00:00
  • 210

微服务

1. 简介微服务的概念最初由Martin Fowler与James Lewis于2014年共同提出,微服务架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,并使用轻量级...
  • zhufenglonglove
  • zhufenglonglove
  • 2016年07月18日 19:11
  • 1492

微服务以及测试必要性

在微服务的时代中,你就不用费心测试微服务了,自带一套完整的监测体系,所哟在微服务的时代,只有用/不用两个选项,你用,你就符合标准来使用,你不用,那就不存在测试 micro Service,p...
  • gnicky
  • gnicky
  • 2016年05月25日 08:42
  • 794

微服务与持续交付

编者按:InfoQ开设新栏目“品味书香”, 精选技术书籍的精彩章节,以及分享看完书留下的思考和收获,欢迎大家关注。本文节选自王磊著《微服务架构与实践》中的章节“微服务与持续交付”,介绍了持续交付是什么...
  • xuguokun1986
  • xuguokun1986
  • 2017年02月10日 14:44
  • 369
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:都在说微服务,那么微服务的反模式和陷井是什么(二)
举报原因:
原因补充:

(最多只允许输入30个字)