最近两年，微服务成为了后端最火的概念。Spring boot和Spring cloud也成为了微服务浪潮的有力推动者。以至于，多年来裹足不前的Java EE也将在今年推出新版本。个人拙见，微服务其实就是分布式服务端系统的一种实践方式。微服务的火爆也体现了后端技术的不断发展，开发者开始着眼于系统的扩展性、稳定性、可用性等等的多重指标，而不仅仅是为了实现目前的需求。
后端技术博大精深，以我现在的水平很难全面地给出总结。所以在此，我从自己的一些实践感受出发，谈一些理解。当然，我会以Spring全家桶作为参考对象，因为Spring的生态圈相对比较全面。
1. 重量级 VS 轻量级
首先明确一下，这里的“重量”和“轻量”指的是对“细节标准”的实现程度。“细节标准”是区别于“标准的细节”。“细节标准”常常作用于“大标准”的子空间里。如果过度地支持这些细节标准，一方面有点走技术死胡同的意味，另一方面说明这个框架或者技术栈的入侵性太强。几年前，Struts还是挺火的，但目前来看基本过气了，个人感觉Struts很大一个问题就是过度使用了servlet标准。servlet就是典型的“细节标准”，目前很多轻量级的后端框架都没有选择servet。这里并不是说servlet标准很差，但是当servlet过度入侵业务代码的时候，确实会带来很多麻烦。
2. 集中 VS 分散
“集中”与“分散”这两个子标题，其实有有些迷惑人的。因为，“集中”与“分散”是要从维度来说的。从宏观系统的角度来说，现在比较常见的后端架构如下图所示：
图中所示的后端架构，相比于传统的IOE（IBM，Oracle，EMC）架构，会显得非常分散。这种架构角度的分散，是有多方面的优势的。《大型网站架构设计》（李智慧）一书中总结出了后端架构的五个要素——性能，可用性，伸缩性，扩展性以及安全性。无需多言，这种分散的分布式架构在多个维度都表现地更为优秀。
以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。
写道这里，已经深夜，就此搁笔了！虽然有些扯淡的意味，也算是一点点思考吧！
发表评论