你好，我是徐昊。今天我们来聊聊如何将8X Flow模型映射为微服务。
经过14-16节的学习，我们已经可以使用合同上下文、履约上下文和领域上下文对业务进行建模了。那么当我们希望在云平台上将业务模型实现为软件系统时，就需要将合同上下文、履约上下文和领域上下文作为系统天然的边界，并将它们放置到不同的弹性边界中，从而在满足业务扩展与需求变化的前提下，尽可能地降低成本。
有了弹性边界，我们自然很容易地想到可以将不同弹性边界内的内容，实现成微服务架构风格（Microservices）。那么今天我们就来讲一讲，如何将8X Flow的模型实现为微服务架构风格。
在开始讨论这个问题之前，我们首先要重申一下什么是微服务。关于微服务，现在有诸多迷思，以及很多看起来像是微服务，但实则南辕北辙的伪微服务风格。
在James Lewis和Martin Fowler的名作《微服务》中，将微服务定义为一种架构风格，并总结了它的九种特质：
具体的内容可以参考James和Martin的文章，其中有三个特别关键的点，我需要专门提出来说一说。正是对于这三点理解的偏差，从而形成了三种典型的伪微服务风格。
第一点是服务按照业务能力划分组织。这个架构特性说的是，微服务中的服务应该以业务能力（Business Capability）为粒度。其实这也间接回答了“微服务到底多微合适”这个问题：既不是单纯的技术能力（比如查询、获取系统时间），也不是完整的应用（Application），而是用以支撑构建应用的业务能力。
所以微服务的“微”是个相对概念，而不是绝对概念。也就是说，与单体应用（Monolithic Application）相比，微服务是微小的。这就好比说，对比银河系，太阳连尘埃都不如。但是太阳就很小吗？并不是吧。
说句题外话。在我看来，软件行业中存在一个神秘的“恰当粒度”（Appropriate Size）。比如很多年以前，当我们使用用例（Use Case）捕捉用户需求的时候，出现过这样的争论：到底用什么样的粒度去捕捉用例最合适？而转换到用户故事（User Story）之后，它直接把“粒度恰当”（Size Appropriated）当作特性之一了。技术上也是一样，但凡出现分布式架构，每一个分布式组件多大，永远是讨论的焦点。SOA（Service Oriented Architecture）基本上就是被这个争论给搅黄的。现在热门话题不又是“微服务到底应该多微”吗？
对于用例的恰当粒度，Alistair Cockburn在《编写有效用例》（Writing Effective Use Case）一书中给出了最佳实践。他将业务和技术比喻为天空与大海。天空中有云彩（宏观目标）、风筝（目标），大海里有鱼（功能点）和扇贝（实现细节）。而恰当的粒度恰好在天空与大海的交汇处：用户目标。它既有业务上的含义，也有技术上的支撑。
到了用户故事就更明显了，它必须包含用户价值与实现价值的行为，也就是说，用户故事必须在业务和实现上都具有指导意义才行。而对于SOA，最佳实践是能力建模（Capability Modeling），以业务能力为粒度进行SOA的服务构建。从某种意义上说，微服务这个词被发明出来，本意就是为了将使用能力建模的SOA（当然还有利用RESTful API而不是复杂的WS-*）与其他SOA风格分离。
你会发现，通常所说的“恰当粒度”是在业务与实现两个维度上平衡的结果。并不会存在“只从单一维度入手，越怎么样就越好”这么简单粗暴的结论。所以微服务并不是越小越好，当小到不能表示业务能力，就不再是微服务了。
如果不顾及服务是否按照业务能力划分组织，就是一种典型的伪微服务模式，我称之为分布式服务（Distributed Services）。要注意，分布式服务并不是反模式，它有其特有的用处，只不过它并不是微服务而已。也可以这么理解，微服务算是分布式服务的一种特例。与其他分布式服务相比，微服务特有的优势，大半都源自按照业务能力划分组织服务。
对于微服务，我要说的第二点是，以产品而不是项目研发。产品和项目的差异体现在团队结构和生命周期上。
从团队结构上来讲，产品团队包含产品研发和产品运营。在产品生命周期内，产品团队负责产品的一切。而项目团队的职能通常会更简单一些，不包含运营和运维部分。快速说一句题外话，DevOps是需要产品团队才能实现真正的研发自运维。
从生命周期上讲，产品的生命周期分为初始、稳定、支持和结束生命这么几个阶段。那么产品的不同版本，可能处在不同的生命周期中。比如我们熟知的Windows操作系统，在Windows 8发布之后，Windows XP依旧有官方的延期支持。
所以产品团队也可能需要在同一时间内，支持多个处在不同生命周期的产品版本。比如1.0是支持阶段，1.5是稳定阶段，2.0是初始阶段，等等。而项目通常假设只有唯一的产物，随着项目生命周期的进展，项目化服务一直在改变。
那么产品化服务的生命周期，实际上相当于承诺在产品生命周期内，服务是不变的。也就是说，只要1.0不结束生命，那么我们就可以一直使用它。哪怕你发布了1.5、2.0、3.0，只要1.0能满足我的需要，并且还在生命周期内，那么作为消费者，我可以无视你的后续版本。那么对于产品化服务的耦合，在产品的生命周期内可以看作是稳定的，并且可由消费方选择是否升级。
但项目化服务通常做不到这一点。项目化服务通常都只有唯一的产品，当服务出现新版本后，之前的版本就默认消失了，对应的消费者也都会受到波及。这就带来了服务间紧密的耦合和修改的传播。
因而微服务需要服务间不仅在接口上松耦合，还要在生命周期上松耦合。也就是微服务可以自主发布，其他服务不应受到影响。产品化是实现这一点的根本途径。如果服务缺乏产品化生命周期，那就是另一个典型的伪微服务模式，我称之为微工作组（Microstreams）。这个模式会产生一组在生命周期上紧密耦合的服务，从而完全丧失微服务的意义。而且随着服务数量变多，这种生命周期的耦合还会带来难以承受的沟通成本。
说句题外话，判断是不是微工作组，有两个特别简单的办法：
对于微服务，我要说的最后一点是，逻辑集中在服务中，编排简单。逻辑越在服务中集中，所需要的编排就越简单，通常通过RESTful API或者轻量的消息机制即可完成。而如果服务中的逻辑简单，那么就会有大量的逻辑泄露到编排逻辑中去，此时就需要使用复杂的编排工具辅助我们的工作，比如企业服务总线（Enterprise Service Bus，ESB）。
选择编排复杂的逻辑，听起来很有道理：既然我们希望在不同场景下复用服务，那么总有一些需要改变的订制代码，我们需要将它们与服务本身分离。分离之后，就能通过编排引擎，帮助我们在不同的场景下重用这些服务了。
然而你会发现，按照这个逻辑走下去，服务往往会变成对于数据的CRUD，然后大量的逻辑存在于编排引擎中，这也是典型的伪微服务模式，我称之为傻服务（Dumb Service）。当服务没有封装业务能力，而架构师又对复用充满雄心的时候，经常会出现傻服务。这不光服务傻，人也不太机灵。
除了上面三种典型的伪微服务之外，最近还流行起了一种伪微服务架构风格，被称作分布式单体（Distributed Monolith）。正如微服务本身一样，我们很难给出分布式单体的确切定义，但是可以描述它的特质。
分布式单体也是通过一组分布式服务构建的应用，但是却具有单体应用的特质：修改其中某个服务，会引发修改很多其他服务；无法有效地水平扩展。
微服务的核心思路就在于将业务能力封装成独立的松耦合的服务。通过这样一组服务，构建企业内的能力生态系统。除了能满足当前应用的需要之外，也为未来可能的新应用提供了坚实的基础。
而分布式单体虽然是分布的，但在逻辑上仍然是一个单体应用。这一组分布式服务的首要目的是高效地服务于所构建的应用。这种观念上的差别（虽然可能不是主观故意的），也造成了我们对技术的不同评价和偏好。比如“用RPC还是RESTful API来设计服务的API”，就能分辨出你是不是真的在做微服务。
通过前面的讲解，我们可以发现微服务架构风格与分布式服务、分布式单体架构的关键区别在于三点：
其实理解了这三点关键差异，很多关于微服务的问题自然也就迎刃而解了。什么样的粒度是合适的？服务之间存在耦合怎么办？我需要多复杂的编排工具？前台的逻辑传递到服务要怎么处理？这些问题只要变成：微服务会怎么做？分布式服务会怎么做？分布式单体会怎么做？然后互加比较，自然就知道应该选择什么方案了。
接下来的问题更偏技术性一些，对于每个服务我们要如何设计它的API？虽然有一些新的思潮涌现，但我个人认为，以目前而言，分布式超媒体仍然是微服务API的最佳方式。也就是说，RESTful API仍然是微服务API的最佳选择。主要有这么三点原因。
首先，我们需要将微服务构成的企业内生态看做一个整体。套用我前同事Ian Robinson的名言_Be the web , not behind the web_（成为互联网，而不是躲在互联网之后）。也就是说，我们应该将企业能力构造成一个web，而不是仅仅将web作为对外暴露服务的接口。
那么怎么才能描述这构成企业内生态的一组服务呢？自然是分布式超媒体。也就是通过超链接表示服务与服务之间的关系，指导客户端完成它对其他服务的调用。比如我们可以通过这样的超媒体描述，来表示完成支付的不同方式：
<article>
<title>订单详情</title>
<p>....</p>
<link href="http://payment.com/12358921" rel="online-payment"/>
<link href="http://enterprise.com/12358921" rel="enterprise-payment"/>
client"/>
</article>
在这段超媒体描述中，我们指明了可以用于完成订单支付的两种方式，一种是在线直接支付，一种是使用企业支付。
这里我们会发现一个有意思的情况，就是如果以分布式超媒体方式去描述服务间的关联，那么其实我们不太在意它到底是单体应用还是微服务结构。所以一旦把眼光放到，通过服务构成企业内生态，并使用分布式超媒体去描述这个类似于web的生态系统时，会发现微服务不过是实现上的细枝末节。
当我们明确了自己真正要解决的问题，那么就需要让服务可以融入到分布式超媒体中。所以RESTful API仍是目前将服务融入分布式超媒体的最佳方式。
第二，URI在表示服务编排的时候，仍然可以保持模型之间的关系。除了通过超链接，将关联的服务与资源联系在一起之外，URI也可以用于表示服务之间的编排。这是因为符合RESTful风格的资源URI可以看做是函数调用。比如，如下的URI和代码是等价的：
GET /users/1/subscriptions
(subscriptions (users 1)) //LISP 函数风格
getSubscriptions(getUsers(1)) // Java
我们可以将这个URI看做是对Users和Subscriptions这两个服务的编排。那么按照对照函数式编程，不同的求值策略（比如惰性求值）也就变成了对于服务不同的编排策略。如下图所示：
对于同样的URI，在不同的场景下，最合适的编排策略可能并不相同。但是URI帮我们封装了这些细节。
也就是说，我们通过/users/{uid}/subscriptions引用了Users和Subscriptions服务的编排。无论编排方式怎么改变，只要URI仍是/users/{uid}/subscriptions，那么对于消费方来说，就没有影响。而妙就妙在/users/{uid}/subscriptions是从模型而来的，因而是稳定的。这一点是其他RPC风格微服务API所不具备的。
说句题外话，URI可以看作求值，是我在我司技术委员会上做的一个闪电演讲的主题。当时听众里有Martin Fowler、Neal Ford、Scott Shaw、Rebecca Parsons等人，他们都是函数式编程的狂热信徒，于是我就讲了函数化URI、Continuation与服务编排等话题。Rebecca和Martin说这个话题在我所有的闪电演讲里可以排进前三（截止到2017年）。有兴趣的同学可自行推导，反正讲之前我只想了20分钟。
第三，RESTful API也可以表示异步。这是一个对于RESTful API常见的误解，就是RESTful API都是同步的。那么如果需要异步调用服务，就无法使用RESTful API了。
然而在HTTP的状态码中，有一个专门为异步设计的202，表示请求已接受，然后我们只需要在header中指明对应的URI，或者设计成特定的返回结构，就能支撑异步结构了。
比如，你想创建一个新的用户，那么API可以返回202表示请求已接受，然后返回对应的创建任务，供你查询创建进度：
POST /users
HTTP Status 202
{
"task": {
"href" : "/user-tasks/12345"
}
}
因为之前讲过的原因，我一般会使用分布式超媒体来描述整个服务生态，而将异步机制放置在分布式超媒体之后。也就是说，哪怕服务间完全以消息机制通讯，在API层面上，也仍然是以资源为主体的RESTful API。如下图所示：
综合来看，如果RESTful API设计得合理，那么微服务只是在实现层面给予了更好的弹性调配空间；而如果API设计得不合理，那么就算把微服务玩出花也没什么用。我的建议一直都是：比起微服务，我们更应该关注如何通过分布式超媒体表示由服务构成的生态，更应该关注如何Be the web。
当我们捋顺了思路，那么将8X Flow得到的模型转化为微服务，就是水到渠成的事情了。让我们再看一下第16讲中得到的模型：
首先，先不管微服务不微服务，以不同的合同上下文和领域上下文为URI的根，将其中模型映射为RESTful API（方法与第10讲、第11讲相同），并构造分布式超媒体表示这一组服务构成的生态系统。
接下来就要拆分不同的服务了。通过8X Flow建模，业务能力有三种表现模式，分别是：合同上下文表示的业务模式，履约上下文表示的业务能力，以及合同前上下文表示的合同签订流程。
理论上讲，每个不同履约项都可能具有不同的弹性边界，而以履约项为单位拆分成细小的服务，仍然可以表示业务能力。然而我会建议你，从合同上下文开始，先将不同的合同上下文作为服务边界，然后再看看是否需要将履约项拆分成独立的服务。
由于合同上下文与履约项通常会处在相同的URI根上，我们可以按照通过URI编排服务的方式，对它们进行编排。示意图如下：
需要再次强调，你并不需要把每一个履约项拆分成独立的服务，这样不一定有什么好处。只有在履约项真的需要独立的弹性边界时，才需要这么做。至于其他两种业务上下文，比照合同上下文处理即可。
另外，对于每个领域上下文，我建议做成一个服务就行了。毕竟在面向对象设计中，弹性边界不是很容易切分。但是只要使用RESTful API，无论服务如何拆分，接口都是稳定的。
今天我们先讨论了什么是微服务，什么是伪微服务。然后讨论了如何使用RESTful API通过分布式超媒体来描述由微服务构成的企业内生态。最后描述了怎么将8X Flow的模型转化为微服务。
你可能会发现，这篇有点文不对题，通篇5000多字，只有最后500字讲了怎么从8X Flow映射到微服务。
首先，在我看来，行业内做伪微服务的人多，而做真微服务的人少。很多问题不值得去解决，因为没有将问题定义清楚。而一旦明白什么是真微服务，大多问题都变得不言自明。
其次，如果对比微服务和如何使用RESTful API构建企业内生态，显然后者重要得多。微服务可能仅仅是我们通向后者的一种方式而已，我们需要更关注后者。
一旦明确了，我们要实现的是真的微服务，并且我们的目的是为了使用RESTful API，并通过分布式超媒体来描述企业内生态。那么“正确的微服务”的做法也就变得简单直接了。所以我在这门课快要结束的时候，给你一个例子，看看怎么样通过定义问题，来简化解决方案。
请你思考一下，除了组织结构之外，产品化的服务会给我们带来哪些挑战？
很期待你能把自己的思考和想法分享在留言区，我会和你交流。我们下节课再见！