基于微服务，打造共享开发平台

采访嘉宾简介

于人，随行付 CTO \u0026amp; 研发中心总经理，黑少·微服务商店创始人，TGO 鲲鹏会成员，中国人民大学EMBA，全栈工程师，拥有14年开发经验，11年技术管理经验。

InfoQ：请您解释一下微服务现在为什么这么受欢迎？它的优点有哪些？

于人：首先是社会发展趋势，眼下我们整处于不确定性时代，外界环境变化非常快，因此企业需要在系统上快速响应这些变化。微服务最大的特点，就是能够快速地响应业务变化。

第二，微服务的特点是功能和业务的有机结合，功能是载体，业务是灵魂，两者叠加构成了一个具备价值很高的产品。

第三，其他方式，比如SaaS方式或者PaaS都无法解决To B的定制需求，很多SaaS平台被定制化需求搞得很头疼，这也是很多To B的SaaS企业的困境。但是，微服务正好能解决企业的定制化痛点。随行付本身就是B端企业，黑少团队有着多年的B端应用经验，我们在实践中就会发现其他模式的短板，当然也有长处。

InfoQ：您认为企业在什么情况下适合做微服务？如果做微服务的话有哪些难点？

于人：企业快速发展期最需要微服务，一个快速发展、快速成长的企业，业务变化一定非常快，并且时间成本非常高，而微服务模式可以快速地响应各种变化。

InfoQ：企业应该怎么做微服务？应该如何分配资源、尤其是人力资源，来有效提升开发的效率？

于人：微服务的理念源自1967年诞生的康威定律，它认为系统要与企业组织结构相匹配。反过来说，企业如果想做微服务，那么它的组织结构也要尽量适用于微服务，比方说敏捷。实施微服务，其实是一整套管理体系的升级，切换成微服务以后，企业的整体开发效率会有一个质的变化。随行付核心架构切换为微服务模式以后，人均开发效能提升了一倍。

InfoQ：当初是什么原因促成了黑少微服务商店的创建？为什么要创建这个微服务商店？这个商店的定位是怎么样的？

于人：这还真是个I can I up的事（笑）。黑少微服务商店是一个微服务\u0026amp;源码的交易平台，创建它其实是从我们的实际需求出发。我们有很多业务在快速发生变化，变化产生需求，可这些需求极大概率在市面有其他团队已经做过了，如果一个公开透明的交易渠道，就意味着每个团队产生需求的时候，都要自己再做一遍，开发行业就只能处于重复造轮子的低效状态。需求积压只会越来越大、越来越多，开发者个体就必须把时间精力投入在低效的重复劳作之中。如果有一个地方，能让我快速购买这些业务模块，根据我自己的需求稍微调整一下，立刻就能匹配到业务上，那我们企业地增长一定会更快。

我们常年服务于B端企业，我们确信这类需求客观存在，我们也试图求助于PaaS模式或者SaaS平台，但是购买之后发现，它们提供的服务跟我们的业务匹配度差强人意。最终，经过这几年微服务技术的积累，我们发现微服务是一种非常适合共享交易的开发模式，它既包含功能又包含业务，对于企业而言，业务是具有实际使用价值的元素，因此我们判断，微服务具有足够的交易价值。

站在我们自己的角度，我们就是B端企业用户，我们有这个需要，而市场上又没有太合适的解决方案，那就自己下场试一试，尝试推出一套解决方案。

InfoQ：和其他同品类的一些平台，比如说Spring和阿里提供的类似服务相比，黑少微服务商店提供的产品和服务有什么优势和特点？开发者如果选择黑少的话，他们可以获得什么样的好处？

于人：如前所述，我们一直聚焦于业务，业务既是微服务商店的起点，也是终点。您提到的那几家平台基本上是底层的技术解决方案，还是以技术为主。刚才提到过，微服务妙就妙在业务和技术的结合，而随行付更擅长业务，我们服务了几百万家中小微企业，我们知道To B应用的企业诉求是什么，知道真正的业务需要什么。在To B的实用性这个维度上讲，我们是有一定差异化的。

InfoQ：黑少微服务商店，这个名字挺有特色的，您说微服务商店里面用到了一些黑科技，这些黑科技都有哪些？

于人：随行付使用微服务架构将近3年，积累了一些实用的技术工具，比如已经贡献出去的一些开源组件，比如基于适用性的微服务开发平台升级等等，还包括我们为了开发人员量身订作的一些自动化开发功能，自动化运维、自动化开发、自动化容器等等。

另外，我们的人工智能测试明年也会上线，现在已经着手在做，方案已经落地，论证环节已经通过，明年就会跟大家见面。

下一步可能有点远，我们还要在人工智能开发这个领域去发力。总之就是通过一些人工智能的手段、科技的手段，帮助开发者更高效地完成自己开发创新，帮助企业更迅速地解决发展过程中遇到的问题。

InfoQ：您在创建黑少微服务商店的过程中，有没有什么让您非常印象深刻困难或困境？黑少又是如何克服这些困难的？

于人：业务和技术上都遇到过困难。首先说业务，黑少微服务商店的核心模式，其实是争取尽可能多的减少软件开发行业内的重复劳动，去重是商店模式的核心，通过去重降低应用开发成本，提升开发效率，释放生产力价值，让开发者们有更多的精力投入到创新型工作之中。去重是整个软件开发行业的共同目标，大家都在试探各种手段，像PaaS平台，或者是众包模式等等，可到底应该选哪条路？最初我也非常迷茫，于是跟大量的技术管理者沟通，也见了很多投资人。大家都给了我很多有效建议，尤其是一位红杉资本非常著名的To B投资人，帮助清理了许多不太靠谱的杂念。前一阵刘润老师有一篇文章刷屏了，To C和To B之间区别的文章，那就是我咨询完刘润老师以后，他总结出来的。大家一起帮助我把这个想法收束到微服务商店这个点上。

InfoQ：有高人指点，事情就变得容易很多。

于人：高人帮我做减法。收束到微服务商店模式之后反推，发现一切逻辑都能推通。这是业务方面遇到的困惑。

在技术上，肯定也有难点，微服务、微服务商店都是新兴事物。微服务我们还算用得早，三年使用经验，团队内有微服务领域的专家，积累了很多东西。最开始，我们并不想自己做一套开发平台，我们一直聚焦做商店，但是商店一定要配套一套开发平台，帮助大家快速开发、在商店上完成组装。

最初我们是想采购一套平台，在市面上找了很多家，发现确实没有能完全满足我们需求的。没办法，就自己做了，但是这套开发平台完全是不以盈利为目的，给大家免费使用。之前随行付的发展也得到过开源社区的大量帮助，所以现在想回馈社会、回馈开源社区。

InfoQ：关于微服务，黑少有很多这方面的经验，也正是这些经验奠定了黑少打造微服务平台的基础。以黑少的经验来看，在微服务开发的过程中开发者应该如何进行架构的选型，黑少有哪些经验可以分享？

于人：我们是由以前以Dubbo作为通信方案的一套架构转到SpringCloud，主要的原因是SpringCloud现在整体的生态比较完整，Dubbo某一部分做得已经挺好的了，但是它在广度方面还是略微差一些。所以我们转向了SpringCloud。在后者的基础上，我们做了6个模块的升级改造，因为Spring的思路是把东西做到“能用”，而我们追求的是“好用”，这也是偏向技术的开发者和偏向于业务的开发者，思维习惯的差别，对于业务而言，不断优化是应有之义。。

InfoQ：以黑少的经验来看，团队应该如何分配人力等各方面的资源，以提升开发的效率？

于人：还是回到康威定律，资源配置取决于公司业务的发力方向，兼顾考虑人员规模导致的协同性问题。微服务有个妙处，它将一个复杂的业务分解成一个个简单业务，那么一个个简单的业务就可以按需匹配，在一个最高效的人数上去完成这件事、聚焦这件事。根据亚马逊贝佐斯“两个披萨”的管理思想，5 ~ 10个人的团队规模效率最高。微服务有高内聚的特点，由5-10个人完成这个服务，与其他团队之间的沟通就不需要那么多，尤其我们平台又解决了团队间沟通协调的问题，可以进行服务组装。每一个小团队就聚焦将自己的模块搞到极致、搞到完美，大家就能“我为人人、人人为我”。

InfoQ：目前，微服务开发经常会面临依赖滞后的问题，开发者应该遵循哪些原则，可以提升开发交付的效率？

于人：其实整个微服务，我们在落地微服务的思想是说约定大于配置，在最开始之前，大家应该遵照的是一套相对更现实的解决方案，我们现在选的是SpringCloud的一套整体的底层框架标准和逻辑，在这个底层协议与基础上做了一些让开发人员用起来更简单、更易用、更人性化的功能，但是底层还是遵循SpringCloud的这一套整体的标准。

InfoQ：您是否在微服务配置方面有一些经验可以分享？在Docker上部署SpringCloud的微服务，如何才能实现配置的自动化更新？

于人：这个理论上讲，实现自动化更新并不难，外面也有一些开源的配置中心都实现了，本身Spring是支持接口调用的。难在哪儿？这就不得不说，为什么随行付推出的ConfigKeeper配置中心被大家欢迎，难点就在于什么时候去触发这个配置中心，如果你部署上去立刻触发，有可能造成灾难性的结果：一旦这个配置配错了，整个服务就停了。这就是我说的“能用”和“好用”的区别，我们为了做到“好用”，做了多重防范措施，首先在配置修改上具有版本之间的比对，改了哪儿一目了然，改了一行就显示一行高亮。

第二，在更新的时候，我们支持手动触发个别的先更新，相当于灰度测试，你更新完了之后看看效果怎么样。

第三，当这个更新发生问题了要快速回轨，这些都是日常工作中会遇到的一些可能出现的问题。我们为了让它“好用”，确实做了大量的工作。

InfoQ：黑少在未来的长期计划有哪些？

于人：聚焦于商店，商店的本质功能是基于互换的信息透明化，具体而言就是匹配需求与供给。为了让尽可能多的模块流通起来、进行共享，我们必须聚焦于微服务的万物互联，无论用谁家的云平台、无论用什么语言开发、无论用什么微服务协议来通信，最后都能在黑少这个平台上完成它们之间的互相调用，这样就能真正实现大共享，实现软件开发行业去重这个理想。

实现这个理想也许需要时间，但是推进这个理想过程，就能为开发者节省大量精力用于技术创新，或者去做自己想做的事情。降低开发成本之后，也会有更多企业、创业者能够受惠于科技，让科技服务下沉到更小、更轻的企业层面——这样才能做大To B蛋糕，如果只是零和竞争， 那么To B革命就无从谈起。