由Spring引发的小总结

= 728

本文出自:【InTheWorld的博客】

aa6f195de38c385d9e66185d2f9e9d48

最近两年,微服务成为了后端最火的概念。Spring boot和Spring cloud也成为了微服务浪潮的有力推动者。以至于,多年来裹足不前的Java EE也将在今年推出新版本。个人拙见,微服务其实就是分布式服务端系统的一种实践方式。微服务的火爆也体现了后端技术的不断发展,开发者开始着眼于系统的扩展性、稳定性、可用性等等的多重指标,而不仅仅是为了实现目前的需求。

后端技术博大精深,以我现在的水平很难全面地给出总结。所以在此,我从自己的一些实践感受出发,谈一些理解。当然,我会以Spring全家桶作为参考对象,因为Spring的生态圈相对比较全面。

1. 重量级 VS 轻量级

首先明确一下,这里的“重量”和“轻量”指的是对“细节标准”的实现程度。“细节标准”是区别于“标准的细节”。“细节标准”常常作用于“大标准”的子空间里。如果过度地支持这些细节标准,一方面有点走技术死胡同的意味,另一方面说明这个框架或者技术栈的入侵性太强。几年前,Struts还是挺火的,但目前来看基本过气了,个人感觉Struts很大一个问题就是过度使用了servlet标准。servlet就是典型的“细节标准”,目前很多轻量级的后端框架都没有选择servet。这里并不是说servlet标准很差,但是当servlet过度入侵业务代码的时候,确实会带来很多麻烦。

2. 集中 VS 分散

“集中”与“分散”这两个子标题,其实有有些迷惑人的。因为,“集中”与“分散”是要从维度来说的。从宏观系统的角度来说,现在比较常见的后端架构如下图所示:

beckend_architecture

图中所示的后端架构,相比于传统的IOE(IBM,Oracle,EMC)架构,会显得非常分散。这种架构角度的分散,是有多方面的优势的。《大型网站架构设计》(李智慧)一书中总结出了后端架构的五个要素——性能,可用性,伸缩性,扩展性以及安全性。无需多言,这种分散的分布式架构在多个维度都表现地更为优秀。

以Spring Cloud为例,可以更好的诠释这个原理。因为Spring Cloud在应用服务里实现了服务拆分,整个架构变得更散了。下图展示了Spring Cloud的典型架构,对比上图,可以很清楚地看出差别——应用服务器的功能被进一步的拆分了。

spring_cloud

但从微观角度(单个应用,或者理解为单一功能的进程)来看,子系统的结构变得越来越紧密。这一点可以从Spring boot以及其他一些Framework看出来,这些新的框架尽可能的简化配置和部署的步骤,从而消除许多不必要的麻烦。 抛开与业务相关的服务拆分不谈,仅仅是业务代码在web容器的部署就可能出现不少问题。一个典型的例子是JSP中的JSTL标签支持,JSTL与servlet版本、web容器版本都有着非常凌乱的对应关系。从目前来看,很多新的framework都开始使用内嵌的web容器。事实上,在更广阔的虚拟化技术背景下,docker之类的虚拟化技术已经在私有云平台上广泛应用。换言之,配置和部署的可靠性和方便性越来越被重视了。

瞎说了这两段,其实想表达的就是——“高内聚,低耦合”在后端系统中的体现。

3. Node.js vs 传统后端语言

Node.js确实是非常火爆,短短几年npm就成为第一大软件仓库,其热度可见一斑。我也不免俗套,跟风地学了个一招半式。js要挑战后端,它的优势有哪些呢?我觉得有以下两点,很可能不全面:

  • js语言有着广泛的群众基础;
  • v8的性能让Node.js坐上了最高效脚本语言的宝座;

这两条看起来很短,其实非常有说服力,因为它们对应着“生态”和“性能”。同时,我认为Node.js挑战后端存在着一下几个劣势:

  • js异步、弱类型、单进程等特性制约了工程师的发挥;
  • js在与编译型语言相比较时,性能仍然比较差;
  • 其他后端语言已经形成了一定的生态系统;

作为一个看热闹不怕事大的人,我应该没有感情上的倾向性。我看来,Node.js在未来在后端站住脚是完全有可能的,但是不会很容易,克服一些先天缺陷还是需要很多努力的。前面有人跟我讨论Python和Node.js的之间的单选题,毫无疑问,我会选择更不熟悉的Python。

写道这里,已经深夜,就此搁笔了!虽然有些扯淡的意味,也算是一点点思考吧!

发表评论