近期又从头到尾写了一个小 java web 应用，上一次完整的写 web 应用程序已是三年前了。
毕竟近年都专注在后端服务架构上，而较少有机会从前端到后端写一个完整的 web 程序。
而每次有这种机会。我总会去跟进使用下最新的 web 技术来开发，毕竟三年前称手的技术工具现在看来已经老态龙钟。
回想这些年的技术变迁与沉浮，不禁感慨。
C/S 的末路
在我进入程序猿这个职业时，主流的企业应用开发还在 C/S 时代末期，而 B/S 架构方兴未艾。
主流的企业系统架构都是 C/S 的。如上图，数据库充当 Server 端，当年非常多的业务逻辑也有在数据库中用存储过程实现的，
而client开发主流就是图中所看到的的三个工具 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 提倡的分布式对象倒是有点异曲同工了，仅仅是微服务还是略微比对象的粒度稍稍大一些。
并且从上面的图中能够看出，现在的分布式服务架构，将专业化分工推向更细的粒度。
早年基本要从页面开发到数据库。都是全栈project师，现在光是页面就有页面构建和 js 开发的区分，
而后端服务的技术栈则更加多样化，技术不停变迁，你我还将在当中沉浮。
以下是我自己开的一个微信公众号 [瞬息之间]，除了写技术的文章、还有产品的、行业和人生的思考，希望能和很多其它走在这条路上同行者交流，有兴趣可关注一下，谢谢。
