三问微服务

微服务是一个越来越热的话题，讨论的问题都大致是我有一个单体大应用，如何拆成微服务？如何拆了微服务，使得微服务之间的耦合度较低？服务之间调用的性能问题？分布式一致性问题？现在也有越来越多的讨论微服务与组织架构的对应关系，但大多讨论的是R&D内部的组织架构关系。太多太多的聚焦都在技术和技术组织本身，在很大概率情况下，你跟你公司的CEO，COO聊这样的话题的时候，他们不睡着就是万事大吉了。

去年8月的时候，我所在的公司入住了微软加速器第八期孵化企业，微软加速器邀请往期校友智齿科技的CEO徐懿的一次分享，智齿做的是toB的智能客服生意，徐懿分享了他们跟客户沟通时，跟客户聊什么，客户会感兴趣。在很多情况下，客户都会对三类事情感兴趣：增加收入、减少成本、管理提效。而在这三类事中，感兴趣的程度在很多情况下是：

增加收入 > 减少成本 > 管理提效

这个观点触动我了。对R&D而言，R&D需要给业务支撑，需要在R&D上给业务提供竞争力。那到底怎么判断衡量做什么、不做什么、怎么做呢？完全可以简单的通过依次问三个问题来回答：

1. 在我所在的领域，使用了这个技术，可以帮公司（或客户）增加收入吗？如果是，是怎么做到的？

2. 在我所在的领域，使用了这个技术，可以帮公司（或客户）减少成本吗？如果是，是怎么做到的？

3. 在我所在的领域，使用了这个技术，可以帮公司（或客户）管理提效吗？如果是，是怎么做到的？

所以，同样的，当我在聊微服务的时候，我更希望的是从增加收入、减少成本、管理提效这三个角度来说。所以，再来一遍就是

1. 在我所在的领域，使用微服务，可以帮公司（或客户）增加收入吗？如果是，是怎么做到的？

2. 在我所在的领域，使用微服务，可以帮公司（或客户）减少成本吗？如果是，是怎么做到的？

3. 在我所在的领域，使用微服务，可以帮公司（或客户）管理提效吗？如果是，是怎么做到的？

同理，在抛开了技术本身内部依赖性的前提下，微服务拆分时的优先级应等于上述三点的优先级。

下面就用分时租赁汽车共享（car-sharing）领域来做例子。分时租赁汽车共享业务，可能很多人还不太了解这个比较新型的业务。相比于传统的汽车租赁业务而言，分时租赁瞄准的是更加碎片化的汽车租赁业务，用户不再需要到门店走繁琐的租车流程，通过APP就能完成汽车租赁，开关车门等操作，更加便捷，并且只需要根据使用的时间和里程进行付费，大多在1.5元一公里，0.2元一分钟左右，按需付费共享，也更加的环保。比较老牌知名的公司有戴姆勒旗下的car2go。

如果我们把car-sharing描述成一个单体应用，大体如下图所示：

当我们讲我们的领域聚焦在智能出行、car-sharing业务以后，就可以开始问三个问题：

1. 在智能出行领域，使用微服务，可以帮公司（或客户）增加收入吗？如果是，是怎么做到的？

通过微服务本身来增加收入的方式有很多种，其中一种最显著的是，但却相对讨论比较少的是，微服务本身不仅仅是指技术IT微服务，更不仅仅是指你部署的server是微服务。而同时也是你面向你的客户，可以更细颗粒度、更丰富类型的服务。在个过程中，我们思维可以适当的跳出并脱离IT。

讲一个很有趣的应用。在德国，收发快递没有像中国的各个小区的快递箱那么的方便，如果快递员在发你快递的时候，你恰好不在家，这个时候快递员就会把快递再带回去。遇到快递员5点到你家，你6点下班的情况。你就悲剧了。所以，戴姆勒开展了一个名为“Ready To Drop”与DHL一起合作的创新实验。当你在网上购物后，你可以指定一台SMART车作为你的收货地址。快递员到了你指定的SMART车旁后，会使用一个交易编码，通过SMART改装后加上的硬件，使用APP把后备箱打开，然后把你购买的物品放在你指定的SMART，购物者在收取时，也就使用交易编码就可以打开后备箱取走包裹。

信息图片均来自 http://www.digitaltrends.com/cars/daimler-smart-ready-to-drop/

在分时租赁car-sharing、Ready To Drop中都涉及到了一点，智能硬件对于车辆的改装，让汽车不再需要通过钥匙的方式被共享，而汽车本身就是一个服务。分时租赁car-sharing、Ready To Drop只是架设在VaaS(Vechile as a Service，车辆即服务) 之上的创新应用。而不管你在加装了智能硬件的汽车上做什么业务，将VaaS从分时租赁car-sharing的上下文中，单独拆离出来，可以加速创新，在较低新增成本的前提下，给客户提供多样化的、便捷的、有趣的服务。

最近很多讨论微服务的文章都提到了康威定律，组织架构会通过系统架构方式体现出来。延生一点，一个公司对外提供什么服务，也会通过系统架构的方式体现出来。所以，微服务不仅仅是针对IT的微，提供IT的敏捷，也更是提供了公司对客户的微，能够服务更多的客户，创造可能的更多的收入。

所以，我个人的原则是，当有人在问我拆微服务的时候，或者我想要拆微服务的时候，我都会问，这样做了，可以增加更多的收入吗？可以创造更多的可能性吗？如果不能，我们可以干点儿别的更加直接的赚钱吗？聊钱似乎有点儿俗，但如果不能创造价值，本身也就只是一个观赏品。

2. 在智能出行领域，使用微服务，可以帮公司（或客户）减少成本吗？如果是，是怎么做到的？

成本的类型很多，我这里想举例子讲的成本，更多的是指研发成本、时间成本。巨大部分公司都是已经做了，即使可能实现落地水平有差。找个年薪五六十万的架构师定义interface，找几个毕业一两年的年轻人敲敲实现。说到这里，忍不住插科打诨一句，在通信行业，有这么一个说法，一流的公司做的是协议定制，二流的公司才是做研发设计与制造。

在讲减少成本的微服务之前，我需要做一个前提假设，这个假设对于车辆规模达到一定数量的车队，比如千台以上。有一些公司，比如有车企背景的公司，在开展car-sharing业务的时候，在开始往往会使用单一车型，这样在车辆的保养、维修、运营上都可以一定程度上的节约成本，形成一定的规模效应。但是，当在某个局部地区或城市，只使用单一品牌、单一车型提供的服务，瞄准的客户群体本身就可能受到一定限制。如果你去浏览神州租车、一嗨租车、安飞士租车这些大的租赁公司，他们提供的车型往往是比较丰富的。这个时候，就会带来一个问题，硬件供应商的问题。现在市场的情况是，硬件供应商很多，每家硬件供应商都会有自己比较擅长的车型，比如德系车或者日系车。同时，每家供应商，也都会有自己定义的通信协议。有的可能是MQTT的方式，有的是HTTP API Gateway，也有的是原生的TCP长连接。这个时候，如果当因为公司业务发展需要，希望使用新的车型，原有的合作的硬件供应商，可能不会那么满足需求，而市场上又有那么多家供应商，哪家靠谱呢？哪家的硬件质量能够达到你期望的工业指标呢？在传统的做法上，可能会先通过网络搜索、调研等方式，确定一个5~10家的清单，然后分别做对接，测试。因为考虑到车本身的复杂性，和第三方接口定义的合理性这些问题，假设一家对接需要2个人周，5~10家就需要10~20个人周，等你倒腾完，再试运营1个月。时间很快就过去了，投入了的20个人周的人力成本，也最终有效的人力成本其实只有2个人周。

那么可以怎么做呢？

前面提到了，如果你的车队数量足够大，你完全可以自己制定协议，我定义了发送锁车指令就是比如说POST /vehicles/{id}/commands "{"type", "LOCK"}"这样，那好了，你要来投标，你就造着我的要求来实现这样一个接口，你自己使用的是MQTT也好、原生TCP也好，HTTP API Gateway也好，跟我没有半毛钱关系，我不需要提供任何的研发资源，我只需要提供一个接口协议标准，一套测试环境、测试框架，和用来做第三方硬件服务注册的功能。其他的事情就完全可以由供应商来做，研发成本、时间成本均摊到各个投标的供应商。使用微服务，就以解决这个问题，如下图所示：

上图中绿色的部分，可以通过我指定的标准接口，来微服务化，众包给不同的硬件供应商。同时，我们可以针对不同大类的通信类型，提供相应的开发模板和环境，从而也加速供应商的开发节奏。比如，如果你的供应商采用的原生TCP长连接，维护链接，启动服务器，基础信息管理，他其实都不需要做。他使用我提供的原生TCP微服务模板就行了，他之需要在实现指定的接口，做二进制消息转换就可以了。而对于平台来说，也就是硬件的采购者来说，我需要的是提供越来越好、越来越稳定的VaaS API层，更完善的硬件GPS、网络监控功能，形成对业务服务质量的监控，也形成对第三方硬件质量的监控（如掉线率），关注点变少，需要的人力成本、时间成本也会降低。这就是一个通过微服务来降低成本的例子。

所以，再来一次，就是，如果你拆的微服务，既不能增加收入、也不能减少成本，那么还有没有其他可以增加收入、减少成本可以做的事？如果是，那还是先做那个吧

3. 在智能出行领域，使用微服务，可以帮公司（或客户）管理提效吗？如果是，是怎么做到的？

实在没兴趣举例讨论这个，有好些已经有的文章在讨论了。

上面的观点，想表达的更多的是，跳出IT本身、跳出IT组织架构本身来看问题，按照增加收入、减少成本、管理提效来排列优先级，更专注于业务价值的提现。