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

六、无因的开发者陷阱

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

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

6.1 做出错误的决定

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

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

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

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

6.2 了解业务驱动

了解业务驱动对于合理设计微服务至关重要，每一个架构师或者开发者都应该先回答以下三个问题：

• 我们为什么要设计微服务架构?
• 主要的业务驱动是什么?
• 最重要的架构特点是什么?

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

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

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

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

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

我经常使用的一种方式借助白板和团队成员一起讨论，如图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等等。

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

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

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

8.2 Schema版本控制

第二种版本控制方式是在契约自身中进行，不需要在header中指定版本号，如图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对象中。