携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第5天，点击查看活动详情

缘由

早几年朋友自营的聊天交友软件奔出头,有了实质收益,却遇到了一些优化上的瓶颈,问我有没有什么优化办法,顺带能不能设计一个能按用户基数百万级的接口支持,当时基于问题以及一些情况做了考量并设计了响应的验证支持,最终还是不了了之，缘由是传统的分库分表,同步，redis等手段,实施起来必须深入到业务场景去划分、投入比率不是个体能够承受的,而且本质上也不是我理想型的最优设计,思路没有展开。

过程回溯

先区别一个问题,软件过程常常分了两种情况，一种是先从0-1优先执行,一种是先做设计优先整体考量。这两者其实常常也是个人在软件过程中常常会反复纠结的问题，“生存还是毁灭，这是个问题” 此类灵魂垂问一直是个不可回避的争端,觉大多数软件合作的battle也基于此产生意见分歧,我也时常在拷问自己。

• 如果你的设计整体考量总是无疾而终的话可以试着去先从0-1弥补执行力
• 如果你的从0-1常常因技术、业务闭环、方向性问题无极而终,可以试着先整体考量再执行。

问题

社交类的业务之前我没怎么了解,本能的刻板印象决定推断,认为优化考量相对比较简单,实际麻雀虽小五脏俱全,该暴露的集中性问题一个不少,以下是一些问题

• 认识新朋友推荐问题,涉及到多个维度及分组,体现在交互上如距离、星座、关系差集等问题

• 用户基础表字段过载,100多个字段,字段是随着业务扩展在递增,但代码的查全部字段没法回溯调整，导致一些接口性能问题

• 过程中包含有大量视图、索引库及优化手段失效,尽管读写分离扩容等其他手段已经上了,还是无法优化数据库瓶颈

• 特定接口能够用redis处理优化的已经处理,现有情况花销最小的优化手段因为变化性和不可控变化比较多,无法进行业务再划分

• 因APP审查问题,需要接口的整体可变性设计即接口的对外访问路由可以统一调整

• ...

  我当时给的优化建议是在花销最小的情况下,按接口及去优化一些特定慢接口,针对推荐侧的问题,由于相关的查询基本都需要即时,可以考虑预生成推荐池,线程补充异步去补充,查看后做减法,维护一个用户相关的推荐缓存能轻量的优化体验,其他统计性的数据,可适当的拆解剥离以接口最小化优化的原则去实施 之后新的相关设计,我考虑了接口IO及数据库主从读写分离以及用户表的水平和垂直划分按300w数据,我的垃圾电脑1秒内相应原则去做设计,着重对用户表的字段拆表，二级表划分，以及分表后的全局查询、跨表查询做了设计,其中全局查询分别对联合表及分表多线程查询做了验证，后来没进行下去的原因是我觉得分表的设计其实没解决本质的问题,数据库层级的设想,其实一直是中心化思想,当多个用户主体关注关联关系时始终有个查全局的过程：如A,B的关系有两种设计,只存一条记录,查询时A或者B去查,存两条关系记录,始终诸如此类的问题很多。

一些关联技术

之后,我设想自己做博客之类的问题又重复考虑这个问题,在设想有没有去中心化办法,从设计上解决数据瓶颈的问题。过程中了解到了一个词儿叫“骨骼化设计”,是一种建模思想,定义好骨骼连接,行为触发特定骨骼的顺序联动,最终返回的数据及细节持续去完善,此时细节的补充被限定在特定的区域，举例：

• 💪听到别人说,跑起来，我决定跑
• 💪接收信息->主观决定->行为（跑）->联动骨骼（左腿-右手-右脚-左脚【执行链ID】）->肌肉(左腿肌肉-右手肌肉-右脚肌肉-左脚肌肉(动作执行))->结果反馈（接口返回） 大致把用户的行为以个体进行模拟设计（因为还没具体验证,图画的不缜密,将就看思路） 即用户的所有处理被集中在行为模型中,相对应的用户的数据也可按照数据实例的形式去存储获取,同样的用户产生的数据也是被用户自己管理,此时如推荐相关的内容,以文章推荐规则为例,用户自身有一个画像,平台汇集画像侧,形成细分的推荐池,结合推荐规则和用户关系数据差集,即可进行个性化推荐。
  但实际上,行为的定义虽然在一定程度上可以,具体的业务粒度的划分没有一个准则其实不是那么好定义验证的,如果我们的骨骼链的定义以业务表作为作为粒度、或视业务复杂情况按业务粒度划分应当具备一定可行性,另外就是快速的验证和定义及变化性保持的问题，最近在涉及业务编排工具时有了结合思路 把业务按照规则链的形式进行配置,快速的优化模型,最终成型后,把规则链逻辑转义或编译成可执行的代码也是一个思路 一般规则引擎可视化编辑我看到目前有很多相对都做的比较好的开源工具,用途多样,如流程、spider相关、规则链配置、业务编排、物联网组态等相关领域都有其特色
  盗个图以业务编排说明

业务系统在发展的过程中，业务的逻辑越来越复杂，简单的逻辑步骤拆分已经不能快速适应业务的变化，大部分时候都是在主流程上打补丁的方式进行业务支持。而且大量的业务逻辑被隐藏在实现细节中，无法从全局看到整体的业务流程。所以在此背景下，需要一个业务编排框架帮助我们将代码逻辑以组件化的方式组织起来，达到快速配置和快速了解业务全貌的作用。

这种业务编排其实适应场景比如B2B中价格逻辑会根据不同的客户、B端、折扣会有不同计价需要一些价格规则配置调整时比较贴近。

题外话

最近看一位老哥分享的大小厂讨论有了这么一番话： 大厂面试你的屠龙技，进去后拧 180 米长的复杂螺丝，不好拧，小厂面试你的螺丝功，进去后要求你用屠龙技，一个人全套搞定整个软件生命周期，全能全干，两边点亮的技能点大有不同，需要的心态也大大不同。 本来很想写个关于技术鄙视链的分享的，这段一直太忙也没时间,总归焦虑时多拷问自己带来的价值和工资是否匹配,一个环境待的时间太久,很容易停止思考,千万千万不要夜郎自大，另外我不知道我为啥之前总忽略个问题，我目前看到60岁在搞程序的有3个、快60想退休却一直没退成继续上班的、个例还是存在的,下回开个题再说,之前的一篇35岁鞋不合脚的问题思考,从反应看大家普遍都有一些焦虑感，也是和这段就业环境和经济状况相关，还是老样子共勉.
昨日之深渊，今日之浅谈
路虽远，行则将至
事虽难，做则可成

PS

目前还只是个引导思路,期待各位老哥能够补充一些细节，交流一下