认识达内从这里开始

随着互联网的不断发展，越来越多的应用软件等被开发推广上线，而本文我们就通过案例分析来简单了解一下，软件开发技术选型需要关注哪些问题。

业务需求

了解业务需求，明确系统的功能、性能、安全以及未来的扩展需求。

示例：在系统模块划分的时候，有的系统会拆分成【WEB】+【JSF微服务】两组应用进行分开部署，而有的系统只会部署一个【WEB】应用。这中间的判断标准是什么?拆出来【JSF微服务】的作用是什么?

能力复用：微服务层具有更通用的模型设计，具有更强的多业务场景复用的能力。在服务运营的过程中，可以按照业务进行垂直部署;

资源隔离：按业务垂直部署，可以更精细化的优化网络，机器等硬件资源。另一方面，将上层WEB应用与底层的微服务进行资源隔离，同样可以实现更精细化的资源分配。

综上所述：如果你的服务没有多端复用和资源运营的需求，就没有必要拆开部署，增加调用链路和机器资源的多倍投入。反之，进行服务拆分，益处则更大。

2技术特性

评估不同技术的特性，包括可用性、性能、安全性、可扩展性、可维护性等方面。

示例：曾经遇到过一个系统，底层的存储层用的是db4o(一款开源的面向对象数据库)，这个中间件拥有很多优点：

•直接以存对象的方式存取数据;

•不需要数据库服务器，只需要一个数据文件，且dll大小仅为300多k;

•数据查询，操作简便且功能强大，甚至不需要使用SQL;

但这里还是不建议使用它，因为我们是分布式集群服务，这个数据库文件只能存储在单机上面，即存在单点故障问题，这是致命的。有时候为了弥补类似的缺陷，你可能需要花费更多的成本。反过来说，如果是作为嵌入式数据库，应用在某些单片机上，它的这些优势就能够显现出来了。

3社区支持

考虑技术的社区支持程度，包括是否有活跃的社区、是否有大量的文档和教程、是否有成熟的三方库等。

示例：分布式调度框架中tbschedule算是开源比较早的了，但是开源之后很早就没有人维护了，如果在普通的业务中轻度使用，应用层做好监控，应该问题不大。但如果是作为基础中间件大范围的使用，显然它在调度过程可观测性方面，zk重连机制方面，调度异常自动恢复等方面急需升级优化。但现实是社区早就已经停止维护了，这就是一个比较麻烦的事情。

4团队技能

根据团队的技能水平选择合适的技术，避免使用过于复杂或陌生的技术。这一点非常重要，否则后期的维护成本和迭代效率提升将成为一个大的难题。

5成本效益

评估不同技术的成本效益，包括开发成本、运维成本、许可证费用等方面。

1.如果有成熟的开源插件可用，我们应该尽量使用它们，而不是重新发明轮子;

2.对于其他团队已经完成的任务，我们需要考虑是否可以复用;

6风险评估

评估不同技术的风险，包括技术成熟度、安全漏洞、依赖关系等方面。

示例：Fastjson是开源JSON解析库，它可以解析JSON格式的字符串，支持将JavaBean序列化为JSON字符串，也可以从JSON字符串反序列化到JavaBean。具有执行效率高的特点，应用范围广泛。现在，在进行技术选型的时候，就需要当心了，原因就是近两年它频繁的爆出安全漏洞，依赖的应用需要跟着频繁的升级版本，修复漏洞。这还只是表象，更为深层次的原因是显现出的安全保障方面的不足，这在技术选型时，是不得不考虑的因素。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。