被称为“中国货运版 Uber"的货车帮，看它如何领跑互联网 + 物流
在中国，各类运输方式中公路运输占比高居首位，公路运输既支撑社会和经济发展的基础产业，也存在着巨大的市场潜力。
有着“货运版滴滴"之称的满帮集团，在合并后继续高歌猛进。在今年 4 月份完成新一轮 19 亿美元的融资后，满帮集团的多个事业群陆续亮相，包括无人驾驶的多个领域通过并购、投资的方式进行了资源整合，开始对物流全产业链条进行布局。
在这过程中，满帮技术团队如何进行微服务技术落地？架构上有哪些亮点和突破？接下来有什么业务发展上带来的挑战？TGO 鲲鹏会带着这些问题，对满帮集团高级技术总监李昊进行了专访。
2017 年 11 月 27 日，一场昔日劲敌间的长期“战争”戛然而止，物流行业两大巨头 —— 货车帮和运满满宣布合并，满帮集团成立。这一合并，也被评为“2017 年物流领域最大的一桩合并案”。当提到这件事时，李昊表示，“当时两家公司占据了行业头部资源，但这些资源都被拉去做车货匹配业务的竞争，结果不仅影响到了两个公司的全面发展，而且对用户造成了一定的伤害。合并，能为用户带来更多的价值和更好的体验。”
事实证明，合并是正确的决定。今年，满帮集团顺利完成融资进行了业务划分，并陆续成立了会员、交易、自营、能源、金融、智能驾驶等多个事业群，推出了一系列新业务。
发展自身的同时，满帮集团还进行了一系列资源整合。2018 年初，为了弥补自身在自营业务上的不足，同时希望给客户提供更好的服务，满帮集团收购了志鸿物流，布局大车队。之后，满帮集团又投资了中国货运卡车自动驾驶企业——智加科技，智加科技成为了满帮集团在自动驾驶领域的独家战略伙伴，双方将围绕高精地图数据采集、大型安全自动驾驶车队商业化运营支持和赋能全国长途重卡的智能化改造等方面展开深入合作，为推进干线物流场景自动驾驶的产业落地进程而努力。近段时间，满帮集团还与交通部信息中心、国家交战办等一系列国家部委和企业展开了数据方面的共建和合作，打造国家级的物流指数和数据标准。
在聊到关于架构的问题时，李昊认为，“好的架构都不是设计出来的，而是根据团队实际情况和业务情况磨出来的。”具体到落地微服务架构，李昊分享了落地微服务的四个建议：
在落地微服务架构之前，李昊认为，要明白解决的核心问题是如何做分布式系统，而不是如何做微服务。
做分布式系统的过程中，可能会遇到很多难点，比如 partial failure 如何感知和监控，流量和资源如何进行调度，数据和状态如何管理等。而微服务只是在分布式系统的建设过程中，为了应对需求的快速变更，在高增速的公司内部构建高效、自治、响应迅速的“创业风格”团队的一些尝试。它的外延涉及到组织、技术、流程等多个方面，而不仅仅是一个技术架构，甚至可以说，技术在其中并不起决定性作用。
其次，我们还需要考虑到微服务对于组织的要求：
个体：需要提前做好知识储备；
团队：需要对目标达成共识。
落地微服务是一件极其复杂的事情，因为会把原来一个单体的应用拆分为很多个服务，而每个服务会产生大量的实例。这不仅需要开发、测试、运维等各个职能的同学们在工作思路上进行转变，而且对于组织和个体的能力也有很大的挑战。
最后在流程方面，CI/CD 是否足够代码化、自动化，是否有端到端全链路的监控、告警和响应机制，能不能基于一个功能足够完备的网关进行灵活的灰度和蓝绿部署等问题，都将决定一个公司是否具备落地微服务架构的基础。
基于以上三方面，满帮集团做了充分的准备，才决定启动微服务架构的落地工作。如若没有相对应的组织、流程上的准备，建议不要追赶潮流做微服务，否则获得的受益比带来的问题少得多。
做决定之前，李昊建议大家多问问自己，“你的业务需要微服务吗？你的规模需要微服务吗？你的团队能驾驭微服务吗？”
微服务虽诞生的时间不长，却因为适应现今互联网的高速发展和敏捷、DevOps 等文化而备受众多企业宠爱。那么我们该如何认清微服务架构的实际价值？
李昊谈到，我们首先需要理解微服务架构并不是一个具体标准的技术框架，当 Martin Fowler 等人提出微服务架构时，就已经强调微服务架构是一种架构风格。
其中，微服务中更细的粒度、去中心化、轻量通信机制等要素，都不算新颖的思路。它能够变成可操作的实践，主要是因为：
1.必要组件的成熟，如服务的注册发现，分布式的配置中心等；
2.理论方法的成熟，如 DDD、SAGA、CQRS 等；
3.关键技术的成熟，如轻量化容器，分布式存储等。
因此，每个公司在落地微服务架构时，都需要根据自己业务和团队的实际情况进行一系列的技术决策。同时，针对各种不同阶段的项目，也需要不同对待。比如对于运行良好的 Legacy 项目，如果规模很大，业务逻辑复杂，那么没有必要去进行拆分；但是如果项目还处于创新阶段，那么也不一定需要用微服务。因为本来可以在一个进程里的通信，如果拆成多个服务就需要跨进程调用，那么可能会导致为开发、部署和运维带来额外的复杂度。
李昊认为，落地微服务架构真正的收益在于，完成组织和思维方面的迭代，在公司里形成小而美，能胜任各种职能的扁平化、自组织、自管理的团队，支撑在传统组织和技术架构下无法实现的拓展和创新。
除了上述所具备的先决条件之外，李昊建议中小型公司落实微服务时，还需注意取舍和节奏。
一开始落地微服务时，可以考虑先做最基础的组件：比如端到端全链路的监控系统，分别基于 K8S 的容器管理平台和 API Gateway，基本上能满足你所有的需求。如果技术能力有限，甚至可以先从监控系统做起，因为它不会影响主干业务。确定系统建设和架构目标时，不妨多关注云原生平台的构成和分层，以及作为一种架构风格的微服务相比，云原生平台具有完整的体系结构，很容易拆分和细化具体的工作内容。
拥有一套基础组件后，则可以围绕服务的设计、开发、测试、上线和运维等工作，开始构建企业自身的 PaaS 平台。平台可以有三个方面的属性：
1.面向可用率和高并发；
2.面向复杂度；
3.面向测试开发。
根据公司自身的特点，可以考虑这三部分如何落地实施，节奏如何掌控。李昊以满帮集团举例，因为满帮集团业务并不会出现类似于 C 端电商应用那么高的并发量，所以满帮集团一开始主要是提高可用率，解决复杂度问题，然后做了打通测试开发运维全流程的云平台。
Service Mesh 一开始是作为一个 Network 层的基础设施，功能在于处理服务间通信，负责实现请求的可靠传递。随着 Linkerd、Istio 和 Kubernetes 的兴起，Service Mesh 演进很快，规模与复杂度显著增加，将服务发现、负载均衡、指标度量、监控、访问控制、端到端认证、限速和断路器等，都纳入其中，涵盖流量面和控制面，跟微服务出现之前 SOA 时代的 ESB 有很多重叠。
基于此，李昊认为，服务网格背后的想法主要是将网络抽象，这跟满帮集团想对物流行业进行的抽象正好是有一个有趣的对应关系，未来，货物的运输应该就像一个 TCP 包。我们不再需要关心车的承载物品，前进的方向，使用的燃料等。这种层次上的抽象意味着，它的实施成本和复杂度都是很高的。要不要做 Service Mesh，需要技术决策者考虑投入产出比：
1.本来的技术栈异构程度有多高，是否需要进行这样的抽象来屏蔽复杂度？
2.对基础设施，运维都有技术和架构上更多的挑战，业务却不会有太多感知，那么开发人员以及公司的收益有多大？
李昊：“凡是过去，皆是序曲”，我听完这个问题回想各个阶段遇到的困难时，这个感受还挺强烈的。人在生活和工作里，难免会遇到挫折，特别是现在不是流行说我们处的时代是 VUCA （volatility—易变性，uncertainty—不确定性，complexity—复杂性，ambiguity—模糊性的缩写）吗？在当时可能感觉它们要把人压垮了，但过段时间再回头看，好像也不是什么大事，解决的方法也没有多么曲折离奇。所以中国人说，“未来不迎，当下不杂，既过不恋”。
至于说具体怎么解决难题的，在技术领域要不被打垮，当然前提是有好的基本功。这跟踢球一样，很多人随着年纪变大、阅历变多，意识和心理承受力都变强了，知道比赛里该怎么办，但就是停不好、传不到、射不准，主要是基本功太差。
然后是心态，要把困难当成自己成长的机会。我觉得在比较好、发展比较顺利的公司里，新人能学到的东西相当有限。而人在年轻的时候，从困难和错误里学到的东西比顺利和成功里学到的往往要多。
所以，我们需要具备好奇心，以及一个走出舒适区去挑战困难的心态。
李昊：首先，做好技术本身跟地方没什么太大关系。我在各种城市里都看到了很多优秀的个体和团队。所以，能不能做好技术，主要跟它是不是你真正的兴趣所在有关，张益唐 38 岁还在快餐店收银呢。
其次，如果你不是有那么大的兴趣，只是当成一个职业，那么回非一线城市发展也挺好。工作嘛，目的是为了更好的照顾家庭。非一线城市生活压力没那么大，程序员每个月赚三四万就可以过得既顾家还富足。当然，如果不能保持基本的学习状态，要保持这个收入水准，需要运气。
最后就是非一线也可以分为好几个档次的。这几年杭州、成都、武汉等城市发展的很快，当地的科技公司和技术活动都在迅速增多，我们可以参考 TGO 鲲鹏会的分会发展速度就知道。以成都为例，今年头条、美团、OPPO 都已经开设了研发中心，所以我相信，未来非一线城市的技术氛围会不断变好。
李昊：客观来说，每个公司都有自身所处的独特的发展阶段。我们公司从一开始单一的车货匹配业务，到目前多个事业群，还没有出现“技术手刃产品经理”或者“杀个程序员祭天”的情况。现在大家都很爱发的“死对头”的故事，大多数是夸大其词的段子。其中一部分是真实发生的事件，我看了后挺心疼这些同行的，因为这些矛盾大多数可以通过流程去管理和规避。
首先，我们要理解这两个职能的本质。产品设计用户价值，技术实现这些价值，两者缺一不可，又有自己的职责边界，相互应该是补位而不越位的。如果技术过于强势地推翻产品设计，或者产品强硬地拍定研发方案或者时间，这就是越位了。
在明确边界的同时，可以做一些组织架构上的保障。比如我们内部产品是尽量闭环到事业部内部管理的。因为产品经理的工作是围绕用户和为用户提供价值的，可以复用的部分不会很多，不可能做一个集中的产品部门很好地服务所有的业务。但我们有统一的技术部，在做好整个基础服务和基础设施的同时，对每个事业部有团队进行定向支撑。这种组织架构也保障了彼此之间既能有配合，也会有挑战，关系比较良性。
其次，我们来看矛盾的本质。产品对技术最大的不满无非是，需求排在 backlog 里面半天上不了线；技术对产品最大的不满无非是，这需求没啥用，催这么急干嘛，以及需求不断变动。我的经验是，确保两端的管理都要可视化。技术团队的 Lead time，WIP（进行中的工作）等效率指标，以及回滚率，MTTR 等质量指标；产品经理的需求质量，包括描述是否清晰，字段是否完整，上线后效果如何复盘，变动是否很多等，可以通过整个团队随时可以查看的看板进行公示。
总之，清晰的组织架构、贯彻最佳实践的流程和管理的可视化，是处理产品和技术问题的关键。