后端技术的选择
大家好,我接下来根据我个人的经验谈谈后端技术的选取。
总的来说,我们先假定我们对所开发的项目做到了前后端的分离, 后端选什么样的技术主要看本团队的技术实力。
本团队的技术实力主要取决于团队里最好的程序员的技术实力,所以以此为基准,我们可以选取如下的后端技术:
.Net Core, Spring Boot, NodeJS, GoLang, PHP Laravel, Python, Ruby on Rails等等。
后端的主要任务是提供API供前端使用,如果有其他的任务要做,比如统计数据,发送通知等等,可以再开发一个独立的后端服务,访问统一的数据源就可以了,这样做的好处也是为了避免在一个单一的后端服务中牵涉太多的内容,避免以后出现程序复杂度不可控的情况。这里就是一个避免从0到1的任务变成0到2的任务的话题。这个话题以后再讨论。
好,继续探讨API的后端服务开发。如果你所在团队的程序员不存在编程语言的问题,也就是说什么语言都通的话,可以通过抓阄的方式选取后端技术。一般来讲,团队会选择自己感觉最舒服的技术去做。
有人可能会对性能方面有些顾虑。这个我们自然要考虑,选取最优化的方案,几个重要因素结合起来,我们才会确定哪个框架适合自己的项目。
关于性能方面的一个重要指标就是处理时间。服务器端跟客户端数据通信需要通过网络传输,网络传输自然要消耗一些时间,服务器和客户端本身的数据处理和显示也需要一些时间,对于服务器端数据处理这一块,在逻辑业务相同的情况下,上述提到的几种后端技术区别并不大。
再一个需要考虑的就是技术门槛和开发舒适度,哪种技术用的代码量更少?哪种技术用着更顺手一些?哪些技术需要的人力资源更少?
在确定好一种技术以后,需要有个人去把程序框架搭起来,比如说,我们首先要把Controller搭好,能够响应客户端的请求,诸如Get, Post, Put, Patch, Delete等等的访问,可以返回一些Dummy数据,不需要实现真正的业务逻辑,这样子做的首要目标是保证让前后端可以互动起来。
接下来会进一步的丰富后端的实现,如果涉及到接口的修改,一定要跟前端协同作战。在这种情况下,我们需要有个懂全栈的人负责把关协调,以确保整个开发流程没有大的纰漏。
一定要避免如下的情况发生,前后端各自为战,后端埋头做后端,前端埋头做前端,老死不相往来,直到最后发现各自都闭门造车的把各自做成了包罗万象的“全栈”,这是非常不幸的情况。
如果任由后端发挥的话,后端工程师会开发出非常多的接口和实现,其中绝大多数的接口可能前端根本不需要的。这样子,增加了工作量,代码量,进而就增加了复杂度。
我们说复杂度,是由几个因素造成的。一个因素是你实际的工作量,任务数,这个时候是加法。1+1+1…, 以此类推。再一个是乘法,就是情况判断引起的复杂度,每判断一次,复杂度成倍增加。如果存在嵌套情况判断的话,最终的复杂就会非常恐怖,如果超过了一个限度,就超出了我们人类程序员所能承受的范围。我们要避免这种情况发生。
所以我一直强调,即使前后端分离开来,也要在各自端开发的过程中有全栈的概念,有问题及时沟通确认。保证各自端口使用最少量的代码完成最大化的任务。
再回到我们后端技术的选取。如果你的程序员:
喜欢Javascript, 那么NodeJS就是你的选择;
有的喜欢用Swift, 那你就用Swift来写后端服务;
喜欢Golang的就用Golang。
诸如此类……
不管你用什么框架,一定要选自己最有自信,用着最舒服最顺手的技术。如果是新的技术,还没有自信也没有关系,可以搜一搜这门技术的用户反馈,社区活跃程度,你关心的技术难点有没有足够的答案。如果某项技术存在很多的用户抱怨,那就没必要再继续探索了。那就继续寻找更好的技术…
具体来说,上面列举的几大后端技术,本质上没有太大差别,性能也很难说孰优孰劣, 这也包括开发难度方面,包括工作量方面,区别并不是很大。
这是因为他们的逻辑层几乎是可以一一对应的。逻辑层包括什么呢?Controller层,Repositoy或者Service层,Entity和Model层,Entity是跟数据库对应的,Model是跟Controller对应的。两者之间的联系可以放在Repository或者Service这一层处理。
这里面有一个后端性能的比较误区,一个说GoLang最快,比其他的后端技术都要快,因为它是Native Code, 其次是SpringBoot和DotNetCore因为是ByteCode, 最后就是其他的框架,因为都是解释型的语言框架。这个层次比较有一个前提就是你极端的关注服务的加载速度。现实中的情况是你的服务起来以后,你可能永远都不希望它停下来,所以这方面的速度可以忽略。
另一个比较的误区是认为NodeJS比其他的框架要慢,因为是单线程的。这个也是没有依据的。先不说多线程会增加程序的复杂度,资源枷锁所造成的计算瓶颈, NodeJS的异步处理机制是非常先进的技术,其他的后端编程语言已经或者也逐步地引入了这种机制。用的好了,可以把非常复杂的逻辑变成线性的复杂度,也就是加法的复杂度。
另一个比较的误区是认为Rust是最高效的后端技术语言,这个也不准确,因为Rust的主战场在操作系统一级,在开发后端服务来说,可以使用的程序库相对较少,社区规模比较小,这会增加你程序的开发风险。所以目前我不推荐你用Rust去写后端。
说到语言的高效,我们不能不提C和C++。 为什么我们很少用他们去写后端服务呢?就是因为太累了。同样做一件事情,比如发送或者接受一个请求,把数据转成你想要的Model。这样一个简单的任务如果交给C和C++来做,可能需要其它语言开发所需要时间的几倍甚至更多。
好的,关于后端开发的话题就先谈到这里,有不足地方请大家指正。
- 点赞
- 收藏
- 关注作者
评论(0)