技术选型背后的思考笔者在工作经历中多次遇到技术选型问题，每次技术选型无一例外地纠结重复。一个普遍的现象是在项目推进过程中，技术选型反复修改，客观上降低了效率。当最终选中某个选项时，结果似乎是显而易见的。为避免反复纠结导致效率下降，笔者认为有必要总结一下模型选择中常见的思路，以供日后参考。每种技术选型都是基于特定的需求场景，结合各种主客观因素，初步做出最优选择。很多人在技术选型时认为只要选择的技术产品满足业务需求就可以了。然而笔者经过多方观察发现，满足场景需求只是前提条件，真正纠结的点往往在需求本身之外。下面根据技术特点、技术管理、权衡取舍三个部分总结了选型时需要考虑的几个方向。1技术特点了解每项技术选型的技术特点是选型的开始，也是必须做好的工作的一部分。笔者通过经验发现，选择过程中的重复和纠结，往往是因为每次选择一开始都没有真正系统地理解。还是继续上面的说法：知道一个技术能不能满足场景的需求只是一个前提，还有很多其他的东西要知道。下面笔者将结合自己的亲身经历一一讲解。1.1满足场景需求的点其实是老生常谈。当然，在进行技术选型的时候，首先要考虑的是每一款机型是否能够满足场景的需求。但是，有几点容易被大家忽略。值得一提的是：了解需求能否被满足，更重要的是了解如何满足需求。对于一些比较简单的需求，可能有很多技术选择可以满足。但是，实现细节上的差异会导致后期的场景迭代过程发生翻天覆地的变化。举个比较笨的例子，某团队需要一个消息队列，那么我们应该用Kafka还是RocketMQ呢？消息队列是一个很简单的需求，但是在不同使用场景的迭代过程中，对消息队列的附加需求会越来越多。能不能持久化，能不能支持EXACTLY-ONCE模式，能不能按时间戳重现消息，读多写多，是否支持事务等等，都会影响选择倾向。很多时候，所有的技术选型都能满足“最低要求”，但没有一种技术选型能够“完全满足需求”。在需求不明确的前期，往往会发现世界那么小，却能找到那么多满足的需求Technology。但当需求逐渐细化后，会发现世界之大，没有一种技术选型可以完美满足所有需求。遇到这种问题，其实有两种思路：一种是“忍”，体现在对不完善的地方凑合或绕过；二是“做”，即想办法发展。1.2完备的技术体系当一个技术选型基本满足场景的需求时，作为技术人员，你要考虑很多场景之外的问题。例如：如何监控、运维一个优秀的技术选型，在设计阶段就会把运维和监控考虑在内，让技术用户清楚地了解系统的运行状态，排查问题。这些配套工具是否完善对于一个技术人员来说是非常重要的。我个人认为，Flink之所以如此火爆，不仅是其技术上的成就，还有其原生完善的运维监控可视化工具。周边技术体系一个大规模的技术选型，往往会绑定很多其他的小型技术选型。比如Flink绑定了RocksDB，Google的很多开源技术都绑定了protobuf。除了关注技术选型主体外，还要注意分析与主体绑定的其他选型能否很好地融入现有技术体系。1.3机器资源评估技术选择上线后，必然会引入机器资源的开销。不同选项的性能可能相差很大。如：rt、cpu、内存占用、网络IO、磁盘IO、存储开销。这里要提的是，上述指标不能只看某一个指标，而是要对所有指标进行整体评价。示例：假设需要选择两种数据存储技术。在线一台机器4T磁盘，500G内存，96核CPU，2GB/s网络带宽。技术选择A磁盘占用1T，内存占用200G，CPU满负荷运行时40%，网络IO1GB/s。技术方案B磁盘占用0.5T，内存占用100G，满载运行时CPU占用20%，网络IO2GB/s。从存储开销、内存使用和CPU的角度来看，选择B胜出。但是由于网络IO选择不当，IO成为瓶颈。如果考虑dockermix，一台机器可以部署两个A实例，但是只能部署一个B实例。由于网络IO的瓶颈效应，方案B节省的存储开销并不能体现在节省机器资源上。1.4技术产品的稳定性你想成为第一个吃螃蟹的人吗？这是个问题。一千个读者眼中有一千个哈姆雷特，但一千个开发工程师对上述问题只能给出两个答案：是或否。新兴技术总是吸引人们的眼球，勾起技术人员的好奇心，使后者产生抢先一睹为快的冲动；可他心里那个理性的小人却一遍又一遍地琢磨着，为了满足一时的好奇心，制造过错，扣了我的工资甚至跑了，赔了我孩子的奶粉钱，值不值？一项技术选型是否有长期稳定运行的先例对于选型人来说非常重要，但如果大家因为这种想法而不愿意去尝试新技术，那么长期稳定运行的先例在哪里呢？？个人冒昧分析一下，决策的关键在于业务场景是新兴业务还是长期稳定的业务，选型失败的后果是否严重，新业务提供的增量价值是否技术能不能打动用户等等，这只是业务原因，这里不做定论。性描写。2管理模式在工作中完成一次技术选型，千万不能简单地从纯技术的角度去思考。一个看似偶然的选择，会对后续的工作产生方向性的影响。这里的影响不仅仅指技术层面，更多的是指管理层面。这就像在一个公司的公开项目招标中，不仅要考虑解决方案本身的优缺点，更重要的是要考虑解决方案的成本是否达到预期，解决方案提供商的实力和诚信，甚至是商业模式。往上想想以后合作的方式是什么等等。而这一切，都可以体现在一个技术选择的过程中。下面就主要阐述在选择过程中遇到的一些常见问题。2.1时间成本和人力成本在决定技术选型时，除了机器资源等成本外，我们不能忘记时间和人力成本也是作为一个团队投入的。在一些牺牲时间的项目中，哪一种选型能够达到快速迁移的目的，几乎可以决定哪一种选型获胜。如果必须使用复杂的技术并且时间紧迫，那么唯一的方法就是通过人工输入。什么决定了投入成本的规模？是增益。不仅是完成项目的短期收益，还有使用该技术的长期收益。因此，就会出现一个有趣的现象。有时候一条业务线的盈利能力可以通过技术选型看出来。2.2维护团队一项技术选型必须长期、稳定、完整的服务于生产，离不开背后的维护团队。小的维护团队可以解答使用过程中遇到的疑难问题，大的维护团队可以派人解决技术选型导致的线上故障。因此，在进行技术选型时，需要考虑以下几点：是否有维护团队，团队是否稳定。.一个稳定的支持团队至少说明这个技术选型对公司来说很重要，所以出现任何问题都会被高度重视。维修团队的技术能力和合作意愿由于不同公司的组织结构划分模式多种多样，并不是所有的维修团队都有很强的合作意愿。总体而言，成熟稳定技术的维护团队在解决稳定性问题和解答技术问题上比较积极，但对支持新特性和使用教学的热情有限；新技术推广维护团队更加积极支持各种新功能。有很强的合作意愿。维修队与自己团队的关系是否紧密，维修队与自己团队的利益绑定是否牢靠，领导是否来自同一所学校等因素都会影响在维修队寻求帮助的便利性。未来。这里的细节往往会在不经意间影响到业务的稳定性和迭代效率。2.3新特性开发模型在业务迭代过程中，经常会出现新的技术特性需求。这时候如果需要在选型上进行开发，就需要为技术开发团队寻找有效的合作方式。常见的合作方式如下：提需求模式就是单纯的提需求，由维护团队开发，大大降低了人力成本，但可控性不强。如果与未归队没有很强的利益绑定关系，是很难容易出现时间延误的。同时，这种模式带来的另一个问题是，自己团队的成员对技术的理解非常有限，很难成长。这种共建方式在新型推广技术中较为常见。业务团队提供具体的业务场景，技术团队进行技术抽象和打磨。在合作的同时，业务团队成员也有机会参与技术开发，提升技术储备。这种做法是双赢的，但对时机和人员环境的要求比较严格。自主研发最可控，团队技术储备增长最快。但需要考虑是否存在重复建设，是否存在增量价值，能否孵化出亮眼的成果。在笔者的实际工作经历中，遇到过如下选型。选型一：基本满足业务需求，技术成熟，很多业务线都在用，但技术是内外黑箱，由一个与团队疏离的团队维护。选择二：需要一定的开发才能满足需求业务需求，技术相对成熟，维护团队和本团队是兄弟团队选择三：完全满足业务需求，是新技术，团队有自主研发能力和开发，但是周边设施不是很完善，和选型一有很多不同重复建设在选型过程中经历了各种纠结，最终放弃选型三，因为无法重复建设，放弃选型2因为兄弟团队不能支持定制化开发。归根结底，我们选择了选型1。3选择选型的核心在于选择，这也是体现一个技术人员技术眼光和综合判断的关键决定。笔者根据自己的一些思考，提出以下实证结论。3.1技术特性的权衡如1.1节所述，很多时候，不会有“完美满足”业务需求的技术选型。这时候，除了定制开发idea，还可以选择绕过问题，弯道超车。这里的“绕过”不是回避，而是集中精力解决关键问题，解决不太关键的漏洞有很多方法。比如有一个集群A，它计算完后会将结果发送给下游的集群B，集群B收到计算结果后将结果写入数据库。我们需要对集群A到集群B的通信方式进行选择。直观上，我们需要一个消息队列来连接集群A和集群B，集群A是生产者，集群B是消费者，我们需要考虑如何保证集群B的机器之间读取的消息不能重复。但是，如果我们手边没有合适的消息队列选择怎么办呢？推进和解决这个问题有两种方式：继续搜索/自定义开发我们可以继续搜索合适的消息队列选择，或者选择自己开发合适的消息队列。这样一来，必然增加时间成本和人工成本。消息队列提供的绕过问题的能力不仅仅是通信，还有持久化、顺序保证、EXCCTLY-ONCE等能力。但是如果我们的业务场景不需要这些额外的能力，而只需要“通信”这个功能，那么我们其实可以使用“rpc单向调用”来完成通信。A集群发送rpc请求，B集群收到请求后立即返回空结果（反正A集群不关心返回的内容），然后进行一些数据库操作。上面提到的案例并不鼓励大家绕过这个问题。其实如果大家都绕过这个问题，就不会有今天那么多优秀的技术选型了。我们要做的是：聚焦核心问题。如果开发消息队列是我们要解决的核心问题，那么一定不能绕过去，要克服困难；但是如果我们要完成一个业务架构的选择，我们不应该过分关注最小的细节。3.2技术管理的选择由于笔者没有实际参与过管理岗位的工作，这里只能从被管理人的角度给出一些看法。在工作中，解决历史问题（俗称填坑）是最没有成就感的工作，“以后填坑”的成本远高于“当时填坑”。久而久之，历史遗留问题只能通过“爆破”（整体重建）的巨大成本来解决。看似破败不堪的系统依旧持续在线运行，每天都要花费大量的人力来维持系统的正常运行。这些都是反复选型引入的长期隐患。因此笔者认为，在技术选型上，维护团队的稳定性、技术产品等因素的重要性远大于迁移成本低的重要性。有兴趣欢迎关注微信科技公众号
