这些年经历的技术变迁与沉浮

最近又从头到尾写了一个小 java web 应用，上一次完整的写 web 应用程序已是三年前了，
毕竟近年都专注在后端服务架构上，而较少有机会从前端到后端写一个完整的 web 程序。
而每次有这样的机会，我总会去跟进使用下最新的 web 技术来开发，毕竟三年前称手的技术工具如今看来已经老态龙钟，
回顾这些年的技术变迁与沉浮，不禁感慨。

C/S 的末路

在我进入程序员这个职业时，主流的企业应用开发还在 C/S 时代末期，而 B/S 架构方兴未艾。
主流的企业系统架构都是 C/S 的。如上图，数据库充当 Server 端，当年很多的业务逻辑也有在数据库中用存储过程实现的，
而客户端开发主流就是图中所示的三个工具 PB/VB/Delphi。

早期我用 PB 开发，后来转到了 Delphi，接触了 Object Pascal，第一次了解了面向对象语言与设计思想，对 Borland 这家公司也充满了敬慕。
再后来 B/S 架构逐渐兴起，一些项目客户要求采用 B/S 架构后，又不得不开始转型。
当时对于网页开发面临两个选择 ASP 和 JSP，虽然只有一个字母的差别，现在回头一想这个选择对后期的转型职业发展可谓影响巨大。
最后，我选择了 JSP，后续就走上了 java 程序员这条道路，但决策的依据仅仅是因为当时听说 java 的主流开发工具 JBuilder 也是 Borland 开发的。

JSP 开启的混乱之治

刚开始学 java 就进入写 JSP 的年代，基本是 java 的乱世时代。
JSP 里有业务逻辑的 java 代码，有操作数据库的 SQL 语句，还有页面展示的样式 CSS 和页面本身的 HTML，偶尔还零星散落几段 js 来控制弹窗什么的。

当我把一个 JSP 文件写到一万行代码时，自己终于受不了，然后大量看书、上网搜索到底怎样写 JSP 才是对的？
然后我知道了设计模式，不止是 GoF 那本书提到的 23 个模式。大模式有讲企业应用该如何架构的，小模式有讲针对某种功该如何写代码的。
最让人分裂的是当时 java 业内正在经历两个派别的大混战，每个派别都有各种不同模式的最佳实践书籍、文章去论证自己是最优选择。
最后搞的我都不知道该怎么写程序了，有人说：

对于初窥门径的程序员，设计模式带来的麻烦简直不逊于它所解决的问题。

是的，我当时应深有同感，本来原本写程序属于拿剑就刺，虽无章法还算迅捷，但学了一大堆招式后每次出剑都在考虑招式用对没，挥剑反倒滞涩不少。

EJB vs 轻量级 J2EE

那时 java 企业级应用开发的正统非 J2EE 莫属，而 J2EE 的核心则是 EJB，EJB 本质上是一种分布式对象技术，提倡对象级的组件复用。
EJB 也正是 java 标准委员会主推的技术，而草根出身的 Rod Johnson 则发起了一场技术思想上的革命，
在《J2EE Development without EJB》这本书的译者序里有句话：

任何一个从事 J2EE 应用开发的程序员或多或少都曾有过这样的感觉：这个世界充斥着形形色色的概念和 “大词”，
如同一个幽深广袤的魔法森林般令人晕头转向，不知道该追随这位导师还是该信奉那个门派。
这时，Rod Johnson 发出振聋发聩的一呼：尔等不必向泥胎偶像顶礼膜拜，圣灵正在尔等自身——这就是他在书中一直倡导的 “循证架构”。
选择一种架构和种技术的依据是什么？Rod Johnson 认为，应该是基于实践的证据、来自历史项目或亲自试验的经验，
而不是任何形式的偶像崇拜或者门户之见。书中谈到了企业应用方方面面的问题和解决办法，而这些方案无一不是这种 “循证方法” 的产物。
除了把这些方案交给读者，Rod Johnson 通过这本书希望传达的、更为重要的信息正是 “循证” 的工作方式——那原本就应该是程序员的工作方式。

那年我刚进入一家规模还算大的公司，在一个项目的技术方案选型讨论会议上，就为到底用不用 EJB 争论个不休。
回过头来看，现在尘埃落定，轻量级 J2EE 胜出，Rod Johnson 创建的 Spring 开源框架取代了 EJB 的位置。
而 “循证架构” 的思想也深入人心，今天我们再讨论技术选型时早已放下主义，仅关注问题本身。

轻量级 J2EE 提倡通过分布应用本身来达到水平扩展的目的，可以换得更快、更简单的编程模型和更好的维护性。
Martin Fowler 甚至在他的书《企业应用架构模式》中开宗名义：

分布式对象设计第一定律：不要分布对象。

以此对 EJB 最终盖棺定论，埋入技术的黄土中，成为历史的尘埃，而以 Spring 为中心的 SSH 类框架应用模式开始纵横江湖。
如果说 EJB 后时代进入 java 领域的程序员缺失了什么，那么极可能是只知有剑（SSH），不知有谱（循证方法），用之而未思之，思而罔之。

SOA 与 微服务化

随着互联网发展，规模越来越大，应用也越来越复杂，即使使用轻量级 J2EE 技术虽然轻量，但业务也变的很重量。
单一应用承载的业务越来越多，越来越复杂，而且单一应用对于大型开发团队的并行协作带来了巨大挑战。

大型互联网公司基于 SOA 的思想摸索了一条新的架构技术道路，以国外 Amazon 和 Netflix 为代表，
提出了一套新的应用架构方式，也即是 SOA 的一种实现：微服务化。
微服务强调服务的单一职责原则，和面向对象设计中强调的对象设计原则一致，
这样有点讽刺的是如今的分布式服务与 EJB 提倡的分布式对象倒是有点异曲同工了，只是微服务还是稍微比对象的粒度稍稍大一些。

而且从上面的图中可以看出，现在的分布式服务架构，将专业化分工推向更细的粒度。
早年基本要从页面开发到数据库，都是全栈工程师，如今光是页面就有页面构建和 js 开发的区分，
而后端服务的技术栈则更加多样化，技术不停变迁，你我还将在其中沉浮。

来自：http://blog.csdn.net/mindfloating/article/details/47029233