帮百度AI干脏活累活的公司，都死了

Posted 2023-05-01

参考技术A

文 | 李夜

在接触数据采标行业过程中，黑智听到一个陆奇和河南标注工厂的故事。

据悉，大部分河南标注工厂用的是百度的标注工具，干的是百度的活。陆奇掌旗百度时，放出了大量采标需求。当时，活不难（准确率只有90%），标注的利润空间可以达到60%—70%。有些企业盲目扩张，一下子招了几百人；陆奇离开后，百度需求恰也减少。2018年下半年，准确率又普遍提高至95%-96%，活难干了。这些工厂只会百度的标注工具，很难接别家的业务，因此死了一批。没有死的工厂不得不裁员，目前处于艰难转型中。

当河南标注工厂艰难转型时，张三的标注公司却正式营业。公司初建，百事繁杂，前几天，黑智才在中午空闲时间，联系上他。他告诉黑智，两个年前的单子需要返工，一直在忙。对于初建公司，忙比闲好。如果有一天空闲下来，张三说他晚上都会睡不着觉，“一天没活干，几千块钱就打水漂了。一个月得支出15万（注：目前，公司有65名员工）。”

在他看来，标注行业是一个苦行业，“前半年，一定会赔钱的，你要做好一个人赔一万块钱的准备。”他笑着告诉黑智，“如果你和谁有仇，就劝他干标注吧。”这是标注圈有名的段子。标注圈说大不大，说小也不小，分了四个梯队。张三说，他的公司属于第三梯队。第一梯队，比如百度众测、京东众智等。第二梯队，比如龙猫数据、Testin云测、倍赛 BasicFinder、数据堂等。他将第二梯队和第三梯队的关系，比做小房地产开放商和搬砖工人。第三梯队之下，是数量巨大的小作坊，团队规模在3-5人之间。

标注行业又是一个有前景的新生行业。

新生意味着不确定与无限可能，“干标注就像将水倒进一个水桶里，每拉一个框就是添一碗水。目前，谁也不知道还能添多久，只有水溢出来时，才知道。”这并不妨碍张三设计未来，“第一步，现阶段先服务好第二梯队，以后搞一个平台，把公司做成第二梯队。”

300亿市场与转折点

数据采集、标注市场有多大？300亿元。

1984年前后，这个市场就出现了。欣博友的公司是众多公司中的一家。当时，这些公司更像一个“录入公司”——将纸质内容电子化，而不是标注公司。“录入”是一个劳动密集型的工作，一家公司需要雇佣很多人来做这件事。智联招聘显示，欣博友在公司人数项上，勾选的是“1000—9999”。

和欣博友不同，海天瑞声成立于1998年，做的是语音标注，自建了很多语音库，业内人士告诉i黑马&黑智，重复销售以前做的语音库是海天瑞声比较大一块业务。数据堂成立于2011年，通常外界对其最深印象是“它是国内最大的数据交易平台”。这和其起家业务相关。

2015年前后，随着以榜单中的人工智能公司TOP50的强势崛起，数据标注和采集需求逐渐多了起来。这个市场才真正意义上形成，也即前面提到的四个梯队。他们作为乙方，进入到这个日益扩大的市场，为估值超10亿美金的AI独角兽服务，教能够改变世界的人工智能产品学习。

1.得数据者得AI的天下

数据是AI公司的必需品。就像人每天需要一日三餐，而AI模型也每天需要数据的喂养。数据和AI模型的关系，倍赛 BasicFinder创始人兼CEO杜霖理解深刻。高中期间，他开始研究计算机视觉，高三发表了论文。大学期间，他也一直在做相关的研究。他知道数据对于AI模型的重要性，并得出“AI建模没有门槛，数据才是门槛”的结论。

在他看来，现阶段的人工智能是简单的认知智能。“认知智能就是帮你去识别、分类这个世界。分类器的构造是个数学问题，就是由数据堆起来的。”“深度学习本质上是个数学问题，是由大量的样本空间数据反向构造分类器的系数空间的过程。你要有很多样本，什么叫样本？知道正确答案的才叫样本。这跟我们小时候求多样式、求系数式是一个道理。我们要有很多空间中的已知点，才能拟合成一个多样式。同理，深度学习也是这个模式，也需要大量样本，也即标定好的数据。”

于是，杜霖认准了“在现阶段工业界的AI应用研发，标数据是一定跳不过去的，可能10年之内都要依赖于标数据。”数据对于AI的重要性如斯，但数据的标注和采集公司并没有学界、业界、资本甚至是媒体的认可，光环一开始便属于那些做模型研发的AI公司，比如商汤 科技 、旷视 科技 等。

“一个公司做成了很好的人工智能产品，大家都会说人工智能算法牛或者科学家牛，但从没见人说数据收集得好的。”Testin云测VP贾宇航说。贾宇航告诉i黑马&黑智，不但镁光灯照不到，数据采标还是个“苦活”。苦到没有人想去做。它很像移动互联网，产品好，没人想到军功章有APP测试者一份。一旦出了问题，第一个被责备的一定是做测试的部门。

2.300亿元数据采标市场

数据对于AI公司的重要性不言而喻。据悉，AI公司投入10%—15%的经费用于数据采标。也有人提到，这一比例为20%—30%。2018年，中国AI公司的总融资规模达到千亿元以上，数据采标的市场约为100亿元—300亿元。其中，有三分之一是AI公司内部的标注部门之间消化的，有一些会被商务流程外包公司瓜分，剩下的25%—33%流向专门做数据采标的第三方公司。目前，AI融资规模约以每年25%的速度在增长。

随着AI技术门槛的降低，越来越多的公司开源了自己的框架，把数据喂进去就能出来一个模型。越来越多的头部垂直公司开始建立AI部门，之前它们多会把业务交给做AI模型的公司来做，这两年，龙猫数据、Testin云测、倍赛 BasicFinder的很多客户不是来自AI行业的客户，而是传统公司的AI业务部门。龙猫数据创始人兼CEO昝智认为从这个角度来看，市场规模并不好算，BAT、小米、京东、TMD等互联网公司和传统行业里的传统企业，它们会拿出多少预算做AI，不得而知。唯一可以肯定的是，这两三年，数据采标的市场规模越来越大。

这两三年，AI模型对数据采标的复杂度和精细度要求也越来越高了。比如说，现在，做一个人脸拉框，人脸的拉框精度要求在五像素以内或者三像素以内；又或是，整批数据精确度需在97%或者99%以上。贾宇航认为，精度的提高是AI行业发展的必然结果。对于AI行业，有一句话叫 Garbage in, Garbage out，低精度的标注数据对于算法没有任何意义。只有能持续输出高精度采标数据，才是一个能持续保持竞争优势的服务商。

第二，更庞大、更多样的数据规模。庞大在于数据量会更大，以传感器为例，随着传感器成本下降，并被大量应用，将有更多大量的数据需要被标记；更多样指的是更丰富的数据维度，在今年的CES展上，松下推出的智能家居解决方案，不仅仅通过电视上的摄像头观测人脸的疲劳度，还通过椅子上的电容传感器，去检测人的心跳。而之前，疲劳检测只是通过摄像头捕捉人脸。将来，更多维度的数据将被收集，不单单是2D的图象、声音，3D的激光雷达以及心跳数据等也将被纳入到采标的范围内。

3.转折点

需求侧的变化，不可避免地在供给侧引起不小的地震。供给侧开始从密集劳动型行业向新产业、新模式——工具+众包转型。洗牌开始了，数据采标迎来了下半场。

受负面影响最大的第四梯队。无论是采标的复杂还是要求愈高的精度，对于它们来说都不是好消息。去年中旬以来，每天十几、二十几家小作坊要求挂靠在倍赛 BasicFinder旗下，这说明小作坊已经失去业务的来源。“他们靠低质量数据和低价抢市场的模式，已经不能持续了。因为AI工程师不能接受低质量的数据，也不能接受不靠谱的交期。”杜霖说。

张三认为，第四梯队坏了规矩。他们先靠低价四处抢单子，而后内测什么样的项目能够在单位时间内产出最多，再去做这个项目。其它项目，则被分包给更小的团队去做。质量难以保证。“他们不算房租、管理等，只核算人工费用。他们的逻辑是一个人一天50块钱，高于这个价就是赚的。于是他们就报100元的单价。而第三梯队需要承担房租，税收、管理费用以及每天的喝水吃饭等乱七八糟的消耗，至少报200元的单价，才可以做。”

早期，第四梯队靠着这种方式，赚了一些钱，回收了硬件成本，并有结余。但2018年初，第二梯队开始做店测，“看看你有多少人，看看你的场地。你不专业，行业正在慢慢把你淘汰掉。”淘汰，意味着没有业务来源，那么多人需要吃饭、拿工资，不专业的第四梯队危机便出现了。即便能够找到项目，采标项目的要求提高，比如准确度要达到95%甚至是99%以上，小作坊必须从团队中抽出一部分人脱产质检和最后的抽检，成本也会上升。

压力，对于行业中的每一个参与者都是同样的。对于龙猫数据、Testin云测、倍赛 BasicFinder等第二梯队公司来说，他们需要创业迭代，他们需要想清楚在这个过程中如何突破自我，不断创新，走出自己的舒适区。他们找到了一个抓手起步，需要思考的是未来怎么才能取得全胜。业界认为，第四梯队危机的出现，有利于实力强大的第二梯队靠着服务质量与效率抢占退出的小作坊留下的市场空白。

新阶段与新竞争

数据标注和采集是一个技术活。

需求来到，采标公司做两个方面的工作，一，调配和研发模块，二，进行试标，并尝试总结规则，并培训。做完了这两方面的工作，公司会向需求方报价，报价过程中，采标公司回去准备相关应标材料或者应答材料。

中标之后，采标公司开始传输数据，上传到平台上，并开始配置生产和标注业务。据悉，数据标注业务的配置是一个复杂的数学模型。比如，有些任务需要串并联的工作流，并联的工作流是多人协同的工作。串联的工作流是后一个结果是基于前一个结果进行处理的，串并联的工作流需要平台来实现业务工作流的配置。比如一些NLP型的文本标注作业，需要多个人来标，最后N选一或者投票。串并联配置涉及到底层数据流的分发等。

标注过程中，质量的协同管理和绩效的统计非常关键。平台需及时统计到每个人的准确率、稳定性以及效率。标注完了之后，客户验收前，采标公司还需要抽检。最后，公司按照与客户约定的格式进行交付，这又涉及到格式转化的问题。

以上过程包含了整个标注系统所有的技术核心点。标注和采集服务并不是堆人就能够干出来的。对于依靠人力的第三、第四梯队来说，贾宇航认为，如果它们想转型众包+工具的新生产方式，“局限性比较大”。理由有二：

一，数据行业的领头者会通过这3年的持续服务，在客户圈赢得口碑，品牌效应会给其带来一定的商业积累。一些更在意质量、更在意投入产出比的公司会逐渐向领头者们倾斜。二，技术优势。头部标记公司有资金去优化自己的工具和应对客户的定制化需求，并通过管理经验优化对应的服务体系和流程。而对于小团队想要快速建立已有工具和流程化体系去覆盖一个或多个行业是有局限性的。有两条路可供它们选择，第一，精简团队，专营一个或几个AI公司的业务，做一个小而美的生意；第二，与精英合作，使用精英提供的工具，做平台分配过来的任务。

对于尚未入场的后来者来说，如果后来者一开始便立志做一个众包+工具的平台，除了克服商务壁垒外，在众包方面，众包平台需要强运营能力，需要足够多的人在平台上。平台方需要考虑如何拉新，如何保留日活、月活等。在工具方面，只有一个可采标的APP也是不够的，没有便捷的沟通方式减少误差的传递，也是很难做成的。这就像木桶理论一样，缺一块板都装不了水。换言之，留给新进入者的窗口期逐渐关闭。

业内人士认为，采标市场将进入战国争霸期。实力强大的第二梯队之间不可避免地面临着一场混战。数据采标市场开始趋于统一。第一梯队注定不会成为争霸期的主角。因为行业竞争等方面的考量，采标需求方不会将数据交给百度、京东的众包平台来做。做人力资源外包的上市公司会在下半场拿到一定比例的市场份额，会对五家标采公司造成一定的威胁，但该威胁不大。

下半场，第二梯队将如何竞争？通过与第二梯队中的三家公司深入交流，黑智发现它们对未来和竞争理解各异，布局也不尽相同。这些差异在它们诞生的那一刻起，便被注定。

1.做轻还是做重？

在回答“做轻还是做重”这个问题上，龙猫数据、Testin云测、倍赛 BasicFinder给出了不同的答案。Testin云测、倍赛 BasicFinder都建有自己的标注团队，而龙猫数据则坚持用众包的形式来做标注。

不同选择的背后，是各家不同的基因。Testin云测成立于2011年，以App兼容性测试作为切入点，进入企业服务，后衍生出功能测试、自动化测试、安全测试、性能测试等服务，成为一站式测试平台。2017年，Testin云测积累了大量客户。一些AI公司找到云测，希望通过云测的众测平台做数据采集。这是Testin云测采标业务的起点。

Testin云测的采标业务做得很重，比如除了众包采集外，它还会做定制化场景采集，甚至和横店影视基地合作，利用横店群演资源，搭建专属场景，完成客户的定制化场景采集。在标注方面，Testin云测又自建标注基地，与房山市政府合作用于数据标注。贾宇航表示，Testin云测所做的一切都是为了客户需求，“通过工具研发驱动保障标注的效率、精度，以及安全性。并通过项目管理、风控管理等方式，确保标注精度达到客户标准，以满足客户对于准确度的要求。”

从倍赛BasicFinder的产品基因上来看，倍赛的工具偏向于团队模式的管理工具，而不是众包模式。2018年12月，倍赛并购了欣博友，前面提到欣博友是一家运营了30年的北京数据处理公司。该公司提需求，倍赛做技术支持。“我们迭代了很多次，每个工具、快捷键、每个设置的优化，都是我们在数据生产中磨合起来的。倍赛接业务比别的公司都晚，2016年基本没接业务，2017年才开始接。我们的工具做得很扎实。”

除了欣博友，倍赛BasicFinder一直在积极拓展产能，杜霖说，目前，倍赛BasicFinder又拓展了将近3000多个人的子工厂。“通过拓展自有产能，实现最专业的服务。”2018年9月，倍赛BasicFinder收购丁火智能100%股权。丁火智能旗下“荟萃APP”已积累数十万活跃众包用户。“我们搭建了一套自主采集系统，再搭配荟萃APP实现数据采集，完成更多样性的任务。”

和Testin云测、倍赛BasicFinder不同，龙猫数据没有自己的标注团队，工具偏向众包模式。昝智和联创，出身于互联网公司，他们更希望用互联网平台化的方式去做采标，而不是“做一个纯的数据工厂”。昝智既往经验告诉他，应该让系统做这些复杂的数据处理，而不是靠人对人的管理。因为人对人的管理非常低效。

据昝智介绍，龙猫数据是较早使用众包模式做数据采标的，“我们用众包把事情做成了，很多跟进者也开始用众包去做。”昝智认为，龙猫数据打造出了“倚天剑”。他不觉得学龙猫数据的人能够做好众包，“早进入这个行业的玩家，有一把宝刀，他们用这把宝刀获得了利益，然后看到别人拿了倚天剑获得了更大利益，为了造倚天剑，他不可能把宝刀丢了。刀丢了，他们可能啥都没了。但不丢刀，他们又很难造出倚天剑。因为人的精力是有限的，思维是局限的，他们不可能一边把精力放在宝刀上，又一边造倚天剑，而且造倚天剑还比我们造得好，这不科学。”

昝智认为，龙猫数据没有宝刀，“接到客户需求，我们只能优化系统，才能保证准确产出数据。对于他们来说，接到客户需求，他们还有退一步的路可以走，那就当场监督大家认真去干。他们是有退路的，我们也没有退路，我们必须把它搞定。有退路的时候，人一急了，就容易选退路了。”据了解，目前，龙猫众包平台有400多万用户，其中只有一千多是做标注的。龙猫数据的标注业务主要由一千多个渠道商团队承担。

2.建模还是不建模？

贾宇航提到数据标注的产业链可分为三个部分：人员、工具以及算法。而Testin云测坚持做好人员+工具，不做算法。“数据具有可复制性这一特点，如果采集标注公司会算法，这有点像一个算法公司找另一个算法公司做标注，这一份数据到底是否用于乙方的提升，这中间存在一定的争议。”“我们是在数据领域服务的企业，而不是卖算法的公司。我们只负责完成企业的数据采标需求就可以了，完成了交付，我们将彻底清除客户数据。”

杜霖或许不会同意贾宇航的观点，因为倍赛 BasicFinder正在打造一款傻瓜式建模系统——用户只需要输入数据，便可以得到一个AI模型。“如果客户想成立AI部门，只需要部署上倍赛的系统上，然后再找两三个AI工程师调参，就可以自己出模型了。如此，标注、采集、建模就会变成一个大闭环了，因为客户懂业务，他知道业务数据应该是什么样子。”杜霖说。

现在，倍赛BasicFinder避免直接建模，杜霖强调，“我们将我们自主研发的私有化标注系统及主流的深度学习框架，统一封装进倍赛的AI基础系统BasicAI，实现AI数据及模型的整个生命周期管理。倍赛不建模，我们只给客户提供一套底层工具，让客户自己去建模。”杜霖解释说，“Tensorflow、Keras及Pytorch这些深度学习库的出现，让建模没有门槛，未来甚至高中生都能够建模。”

如果一个 汽车 公司让倍赛BasicFinder帮忙做一个自动驾驶系统，杜霖表示做不了。但他也说，“我们的BasicAI实现从标注到建模的高效流程管理。客户在倍赛标数据，数据流到建模平台，客户在Tensorflow里调点参数，模型就出来了。” 今年，倍赛将推出3.0新版本，同时提供SaaS化标注工具服务，帮助客户实现数据标注管理。杜霖提到，为团队打造的采标及建模流程化工具，可以提高倍赛的业务延展性，提高竞争中的优势。

选择无优劣，但市场会给所有选择一个清晰的答案。而战国混战，或在接下来的几年见分晓。不过，客户并不希望一家独大，大树之下，寸草不生的局面。未来，数强并立的局面或将长期存在。

走向终局

一个场景，一个市场，一个产业，一个江湖。

熙熙攘攘被裹挟着进场的人，有的主动选择，有的则是被动，但一旦进入，市场和资本的逻辑发挥作用，他们你我都变成生产链上的生产要素，被挑选，被进步，亦或被淘汰。

各个产业参与者的位置，从诞生起或已被注定。从产生的那一刻起，它按着既有逻辑在走，从不以个人意志转移。上半场，草根英雄辈出，拼价格，下半场拼品牌、服务与效率。精英开始清场，草根离场或者重新站队。而资本，加速整个产业迭代。

现在，下半场刚开启，谈终局似乎有些为时过早。有太多的不确定将在接下来几年的竞争中，变得确定。但更多的不确定性，可能又会出现。城头变幻大王旗，只在一瞬之间。

黑智认为接下来几年，不确定性虽是主流，但仍有几件事是确定的：

1.下半场仍将是性价比之争。客户永远希望用最小的成本获得更高质量的数据。为了生存和在竞争中脱颖而出，供给侧不得不迎合性价比需求，他们不得不通过技术来获得降价空间和利润空间。贾宇航觉得，技术永远是最重要的。“通过技术的方式倒逼自己不要赚太多钱。如此，价格才能降下来，竞争力则提了上去。”

2.不要忽视传统公司的AI需求。毫无疑问，接下来几年，传统企业的AI需求将会出现井喷，如何抓住他们，并服务好他们，这是所有采标公司亟需思考的。当然，也不能忽视AI行业的新数据，比如3D的激光雷达以及心跳数据等。

3.不能忽视商务能力。不强的商务能力，或将成为采标公司的新短板。现阶段，它们的产品和商业模式已基本经过市场的验证。他们需要通过放大商务杠杆扩大产品的覆盖范围。

4.建立第二条增长曲线。接下来几年，有人离开，有人留下。每个人都有所归属，在产业链上，支配或者被支配。所有留下的公司都应该寻找第二条增长曲线，如此才能突破现有成本收益的限制。另外，张三的梦仍需要做，仍需要努力实现。梦想总是要有的，万一实现了呢。（注：张三为化名）

聊一聊系统重构

开始想聊这个话题的时候，我是打算放弃的；因为这个话题涉及范围之广，内容之多，让我犯怵；

打破常规，重立新规；

01

开始想聊这个话题的时候，我是打算放弃的；因为这个话题涉及范围之广，内容之多，让我犯怵；

近几年，待过两家公司；一家经历过重构，另一家也打算重构......

其实要下定决心，推翻重来，是一个很有勇气的决定；

归根结底，不到万不得已，谁想这么玩，谁愿意花费大精力去做这些脏活、累活；

所以究其原因，也只能说是一种综合因素吧，就像古话说的，天时、地利、人和；

至于为什么这是个很有勇气的决定，因为做重构这事的团队风险极高；上至业务高层，下至底层码农，都有可能一个不小心就被刀；

我曾经待过的一个团队，经历过一次重构，不过那是一次失败的经历；

开发预估了两个多月的时间，业务大佬决定，期间直接对新需求停滞；但是，最终上到生产的系统，老问题还在，然后又多了很多的新问题；

再后来啊，业务大佬和技术主管都被刀了；然后系统回退成老版本，重新承接新需求，并且开发时间被严重压缩，导致技术部门没日没夜的加班；

下面，我大致做了归档和整理，从这八个方面重新聊一聊系统重构；

02

【重构原因】
其实上面也提到过，这是一个综合因素，可能是各种各样的因素叠加，造成一个不得不重构的结果；

下面，聊一聊我所碰到过的因素；要是没聊到的地方，也欢迎大家补充；

第一个，可以归结为系统的稳定性或可用性：不管吹得怎么天花乱坠，你的系统总要可用吧，所以说可用和稳定是一个系统的最基本要求。开发一个需求还要全服务停用吗？业务量增长，系统还能抗下所有吗？那么问题来了，怎么保证可用和稳定？

首先，如果你是单服务系统，那么为了保障可用和稳定，需要对服务进行扩展，加入更多的机器来分担系统的性能压力，也就是常说的“服务集群”；

但是，往往我们的系统并不是单服务的，也就是我们常说的分布式微服务；这种情况下，就不得不扯到分布式的三大法宝：限流、熔断、缓存。相信要实现这三个法宝，有很多成熟的框架和工具等，这里就不过多阐述了；

第二个，开发规范问题：这也考验了团队leader对底下成员的约束力，以及是否存在代码review的环节；

假设一个团队，leader确实没有对成员强制约束开发规范，更别提代码的review了；最终导致的问题就是，各写各的，每个人都有自己的一套开发习惯和开发规范；最终就是一个大写的“乱”；

这样日积月累，一代目埋坑，一代目撤，二代目上，二代目撤...... 系统不知道经了多少开发人员的手，最终，新入职的冤种某天需要排查一个产线问题，仿佛误入了代码的迷宫，深陷其中，无法自拔；

第三个，推翻原先核心业务，重立新规：这个要解释起来比较麻烦，也碰到会比较少，然而，我恰恰就遇到了；

某天，业务大佬宣布，目前做的这套业务规则要被废弃了，他们重新拟定了一套全新的规则，意味着先前不知道几手的代码已经失去意义了，几乎90%都需要重新写；

都到这一步了，那就大刀阔斧的改革吧；出事了，emmm，业务的锅；

03

【重构会议】
既然已经确定要进行项目的重构，那么拉成员例会是必不可少的，不然就会一片迷茫，不知道干点啥；

第一次会议，由技术老大牵头，叫上业务负责人，技术主管，开发全员，测试，产品，运维；

一般，第一次这种全体会议是没有结果，但是又非常必要的；因为上级领导需要知晓整个重构涉及到的点，影响的方面，开发的时间，以及整体的技术方案，参与的人员，还有需要的资源等等；

第一次会议消化完后，很快就是第二次会议；这个会议也是由技术老大牵头，参会的主要是技术主管和参与开发的人员和运维；主要是对系统重构进行总体的技术选型，讨论用到的框架，组件，实现的方案，部署方案等等；

这个会议持续的时间会比较久，大家搬好小板凳，准备打持久战，可能从上班开始，到下班点了都还不能结束；当然，还是会有中场休息时间的；基本可以各抒己见，提出自己的意见和看法；主要是围绕做什么？怎么做？做多久？这三个疑问点讨论；

接下来，就是由技术主管组织的技术部内部会议了；由于之前已经确定好了统一的技术栈和实现方案，这一次讨论都是在此基础上展开的；

当然这一次会议可能需要更久的时间，因为涉及到是微服务的话，就避免不了一个问题：“服务拆分”；

大家都知道，微服务是需要根据业务去进行拆分的；那么问题来了，业务的划分界限是什么？为什么A业务部分要包含A1，A2，A3；其实这里就需要大家达成一个统一的认知，也是这次会议要达成的最终目的；

这次会议最后，服务已经划分完毕，但是缺少去维护这些服务的人；那就需要对开发人员进行分组，每组有对应的负责人，看人员情况而定（如果就两三个，甚至更少的开发，那就没必要分组什么的了，就是冤种，活都得你干），每组对N个服务的开发和维护；

分组过后，组长会进行简短的组内会议，这次其实就是派活会议，认领各自的工作；也会明确一点，大家要干些什么？谁干哪些？每个人干完都需要多久的时间？

最后，会整理一份排期计划，上面每个人的名字赫然在列，当然还有任务列表，工时，等等；

一切准备工作就绪，最后就是开干了，当然后面开发过程中还有一些不明确的点，也会临时组织一些会议，让大家达到统一的认知；

04

【并行需求】
在系统重构的开发过程中，因为占用的周期会很长，投入的资源会比较多，所以难免还会遇到这样一个问题；

一天产品经理急冲冲的跑过来说，现在有一些需求很着急，需要将重构停一停，先把这些需求排期上线；至于为什么会这么着急，咱也不知道，咱也不敢问呀；

这时候就会面临一个恶心的局面，这次开发的需求，肯定需要在原先的服务中进行开发，那么重构的服务中，是不是还需要再写一遍？

王德发！说归说，骂归骂，办法总比困难多！这时候有一种方式，那就是派出个谈判专家，以三寸不烂之舌，动之以情，晓之以理；多说说技术难点、痛点，占用的资源，实现的难度等等，去打动他，说服他，让这次需求排在重构后面；

如果你成功了，那么恭喜你，这次重构任务，大家帮你分担一半；

什么？产品经理不同意；那就没有办法，只能在改动老服务的基础上，记录调整的点，最终在写新服务业务代码的时候，将改动的点一并加上去；

最后在提测的时候，通知测试同学，这些需求相关的地方，在重构的新服务上线之前都需要重新走一遍流程；

当然，还有一种情况，就是像我之前说的，需求即伴随着重构；这种需求也肯定是大版本，开发周期较长；这种情况是最理想化的，只需要按部就班的进行开发即可；

05

【技术选型】
这个话题，在上面的会议模块已经提到过了，这里再来详细的聊一聊；

当然，这次也仅限于比较流行的分布式微服务的技术选型；单服务的话，额，暂且不说吧；

其实也没什么好争议的，对于Java系统而言，无非就是spring全家桶无脑往上堆，服务器资源拉满；就像买汽车一样，越豪华的车，堆的配置越多，价格越贵，但是舒适性和操控性也就越好；

但是还需要考虑一些因素：成本、产品开源与否、技术社区活跃度、产品的成熟度、结合实际情况等等；

成本：时间成本、学习成本、金钱成本；

事情是人做的，代码也是人敲的；需要考虑团队成员擅长哪些技术栈，如果一门技术只有少部分人会或者都不会，那就需要结合开发时间，去斟酌需不需要用它，即便是热门的技术；

当然啦，如果老板愿意出钱，直接买各种付费的技术就行，我们只需要搭好基础的框架，然后往里面填充业务代码即可；如果不行，那就老老实实看看免费版，出了啥问题，只能自己排查去解决；

产品开源与否：说到这个，开源是关键，最香的词“开源免费”；

就像上面说的，一旦遇到了什么问题，其实有必要去看这门技术的源码去解决的；比如典型的SpringBoot自定义starter，需要定义“META-INF/spring.factories”文件，将文件中配置的类型信息加载到 Spring 容器；

一旦你闭源，那怎么玩？我怎么知道你内部怎么去实现的？只能看官方文档，看你自己吹什么什么功能；

技术社区活跃度：这个因素其实和产品开源可以归为一类，都讲的是一旦这个框架或产品出了问题，我们就可以去它的官方社区上找类似的解决方案；如果一个产品连社区都没，或者活跃度很低，那也就意味着你只能靠自己去解决了，那花的时间成本可就......

产品的成熟度：我们选用一款合适的产品，首先它得符合我们主要的需求，而后它才有其他额外的功能，这当然是最好的；因为一旦咱有一些特殊的业务场景，恰巧这些额外功能正好符合你这个场景，岂不美哉；这样就不必要接入额外的产品或组件了；

比如Redis，大家都不陌生；相信这个工具大家最多的是用它做缓存，它确实也是一款优秀的缓存工具；

但是，我之前在做OA软件时，碰到这么一个需求；用户申请一个会议，并且指定了参会人员，当在会议开始前15分钟，前5分钟，分别对参会人员发送一个提醒；

典型的发布、订阅的模式，然后正好Redis就有现成的功能，当时就是用了Redis的这个功能；

但Redis适合小型应用，如果是大型架构，相信还是会使用rabbitMQ或者kafka等更专业的MQ队列软件

结合实际情况：说到这个，有句老话说：“只有适合自己的才是最好”；在考虑需要用到哪项技术时，最理想的情况那就是直接付费购买，出啥问题，都是有技术支持滴，我出钱了，你得为我解决，但是，成本有限啊；

当然，有些人会说，技术选型这玩意，那是技术主管或者技术总监他们决定的，我们小码农只管拧好螺丝就行；是的，往往很多时候就是这样；但是，你不去大胆说出你的想法和意见，你怎么知道他们不会听取呢？格局打开，往上一层考虑就对了；

06

【服务划分】
这块内容其实可聊的没多少，但是，也是最难的一块；

首先，划分；怎么分？按什么标准去分？分多少服务合适？分好之后怎么去管理？安排那些人去管理？等等一堆问题；

我也只能浅谈下我之前做过的一次划分经历，因为每个公司遇到业务和场景是不同的，最终得到的结果也是不同的；而且，服务并不是一次划分就能结束，它是一个持续不断的过程；

当时我们是全部参与这次重构的开发一起拉会议的，在此之前，已经确定好了技术栈，就是热门的springcloud全家桶；技术主管先是浅谈一波他自己的想法，然后让大家在他划分服务的基础上，提出自己的看法，并且每个人都要说，因为不可能想法都是一致的；

我记得比较清楚的是，他划分中，有个序列号的服务，就是这个服务专门去生成序列号；后面几个人都点名这个服务也包括我；其实当时想的是，我们的系统业务里没那么大，能省一个服务，也是省一点资源；最终大家统一共识，将这种场景写一个工具类去处理；

最终讨论后，达到的共识，也只是一个初步的共识；随着业务需求的增长，一部分业务服务必将变得臃肿，那时候第二波拆分也就随之到来了；

07

【开发规范】
上面提到，造成系统重构的因素有很多，其中一个因素就是代码混乱，大家各有各的习惯和规范；

其实不难发现问题了，并不是每个人不知道开发规范，而是大家没有统一的一套规范，大家只是没有达成共识；

那就来解决这个问题，制定一套统一的标准，让大家都没有异议的一套规范；

这时候就不得不提到阿里的规范，现在广为流传的《阿里巴巴Java开发手册》，甚至基于这套规范，在IDEA上还有专门的检查插件可以安装；

当然，这样做确实省事，省去了leader对代码的review时间，包括我之前待过的一家公司，也确实就是这么做的；

其实仔细用过几次这款插件就会发现，有些检测其实大可不必，但是你又不得不去遵守它的规则，这时候反而徒增工作量；

遇到这种情况就需要看上级了，可以把这个疑问点反馈给他，或者反馈给身边其他的小伙伴，起码让他们GET到你要表达的点，引起大家的共鸣；相信越来越多的人反馈这些问题，上级不会坐视不管的；那么恭喜你，又去掉一块大家都认为不合适的规范，让你开发不绕弯路；

总之，总结起来就是一句话：没有标准，大家统一认可的就是标准犯规；

08

【数据、接口迁移】
谈到这个，除非开发的是0-1的项目，否则在平时开发中，或多或少都是会遇到的，而非重构会单独遇到的问题；

而我们在入职一家新公司，或者长期在一家公司干活，遇到0-1的项目几乎没有；如果有，那么你的运气很好；

就拿我上面的经历来说，业务推翻了之前的规则，重新制定了新的业务规则，那就不得不引出一个问题，之前的老数据怎么办？

这个时候就需要跟业务确认，这批老数据是否可以按照某种默认的规则，做统一的处理；或者说，直接废弃不管；一般来说，按前者处理的方案居多；

考虑到重构，往往你的表也是重新设计过的，也有可能是老表和新表公用，一般来说后者的情况居多；

其实，说白了就是在老表里面去修改数据，在新表里面去新增数据，而我们要考虑的是这批数据怎么去调整比较合适；

按我们之前的处理方式，如果涉及到的表，字段等较少，存储结构也颇为简单，是可以直接用SQL脚本去解决的；另外，还需要考虑如果表数据较多，SQL执行快慢的问题；

还有一种情况，要是涉及到的场景很多，处理的表也居多，可以考虑写程序去解决；比如，写个任务，去手动执行这个任务，处理掉这批数据；当然，也得考虑数据量的问题，如果数据量大，用多线程跑批，或者多服务跑批等方式；

下面，来谈谈重构中的接口迁移；

要保证一个原则，就是对接口的出入参保持不动；不然，前端直接飞过来跟你聊人生；

但是，老服务的接口很多怎么办？还能怎么办，分工处理；

上面提到过，我们是分组的方式，每个组负责一部分服务，分工比较明确，所以相对来说，也比较快；

大家整理文档，老接口的URL是什么，新接口的URL是什么，出参，入参能不变就不变；如果真的需要调整的，需要给出合理的解释，大家一致通过后，然后自行跟前端去battle；

有些老服务还会运行一段时间，所以并不是所有接口都会涉及到迁移，这种接口，那就相安无事；

在迁移的过程中，肯定也会遇到各种问题；比如举个简单的例子，之前老服务的分页插件使用的是PageHelper；而在新服务中，由于用上了Mybatis Plus框架，那自然也就用它框架自带的分页插件了；这个时候就涉及到修改，你只能自己内部消化了；

最后，当你觉得一切接口都迁移完毕的时候，别忘记对自己迁移的接口，进行一次自测；不要怕麻烦，这个自测对于后面的联调和提测流程，都可以免去很多不必要的问题，也可以大大提高团队的效率；

09

【实现方案】
最后还有一点，业务场景的实现方案；这个听着有点抽象，其实在上面说的会议中，也会涉及；

不要以为这只是技术的决定，其实产品的参与也是很有必要的；你品，你细品；

我拿一个经典场景举例，A账户往B账户打钱，然后系统是微服务，很熟悉吧；

没错，就是分布式事务的一个经典场景，要保证数据的一致性，A被扣钱的同时，B要加上相应的钱；

分布式事务我不多说，相信很多同学随便一查，各种五花八门的方案；

但是这里我只讲一点，达到数据一致的时间节点；你是要什么时候保证这个数据达到一致，也就是说，强一致性还是最终一致性；

要求强一致必然是牺牲掉一部分性能的，要求最终一致性就有可能在一段时间内产生数据不一致的问题；

这个时候，就需要拉上产品经理，跟他阐述其中的缘由，说明技术方案上无法规避的点，让他做取舍；

有的时候，好的设计往往能规避技术上的难点，也可以节省开发的成本和时间；

所以，在讨论这块内容的时候，必须要有产品经理在场，提出设计上不合理之处；我们不能只局限于研究技术问题，其实换个角度，或者你质疑的点，就不存在了；

记得实习的时候，公司的老板讲过一句话“人人都是产品经理”，现在回过头一想，还真是那么回事；

大胆的提出自己的意见，做一个有自己主见的小码农；

10

对于系统重构，我就以一句话结尾吧，这也是引用了一位大佬的话，“对公司现有的资源和战略妥协，在技术栈和方案之间取舍”。

编程文档：
https://gitee.com/cicadasmile/butte-java-note

应用仓库：
https://gitee.com/cicadasmile/butte-flyer-parent

Gitee主页： https://gitee.com/cicadasmile/butte-java-note