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

都在说微服务,那么微服务的反模式和陷井是什么(一)
http://www.jianshu.com/p/3986239138fe

六、无因的开发者陷阱

名字来自詹姆斯·迪恩演的电影《无因的反叛》(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对象中。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 141,390评论 1 297
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 60,682评论 1 254
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 93,205评论 0 211
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 40,718评论 0 171
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 48,406评论 1 250
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 38,590评论 1 170
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,271评论 2 267
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,052评论 0 163
  • 想象着我的养父在大火中拼命挣扎,窒息,最后皮肤化为焦炭。我心中就已经是抑制不住地欢快,这就叫做以其人之道,还治其人...
    爱写小说的胖达阅读 28,801评论 6 227
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 32,404评论 0 212
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,176评论 2 212
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 30,489评论 1 222
  • 白月光回国,霸总把我这个替身辞退。还一脸阴沉的警告我。[不要出现在思思面前, 不然我有一百种方法让你生不如死。]我...
    爱写小说的胖达阅读 24,156评论 0 31
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,031评论 2 210
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 31,402评论 3 201
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,583评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 25,927评论 0 163
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 33,352评论 2 228
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 33,478评论 2 229

推荐阅读更多精彩内容