时代在变迁，技术在变革，我们所处的环境也一直在发生着变化。浅谈一下对应用变迁的一种自我认知，尝试去理解这种变迁背后深层次的原因。
传统垂直架构
还清晰的记得第一次搭建tomcat，第一次做web服务。从jsp、servlet、JDBC实现编写的第一个完整的web应用。MVC三层架构的理解与实践。至Strust2、Spring、SptringMVC、Hibernate、mybatis的学习、理解、应用。更多的出发点，也仅仅只是想要掌握这些技术。
这就是一个典型的垂直架构应用。本地应用间的API调用。
特点：
- 技术比较单一（如SSH、SSM技术的集成）
- 学习成本低（会用才是重点、无需了解其原理）
- 开发上手较快（一个基本的DEMO，就能对着业务进行开发）
- 测试、部署、运维比较简单（LAMP）
- 整个应用模块都部署在同一个进程内，一旦发生故障，整个节点宕机。
面向服务的架构
随着越来越多的垂直架构，异构系统之间的通信与数据交换成为需求。以RPC框架为基础，各种面向服务的框架开始流行。如Dubbo+Zookeeper等技术。RPC本身只是一种进程间的通信方式，允许像调用本地服务一样调用远程服务。个人觉得比较原始一点的面向服务的架构，应该是基于WebService搭建的ESB（企业服务总线）。其三要素完整的表述了一个服务，UDDI目录、WSDL说明书、SOAP协议。实现跨平台，跨语言的服务。当然还有RESTful。
微服务架构
目前能够理解的，也就是其原子服务，专注于做一件事，“高内聚、松耦合”。功能越单一，也就意味着对其他的功能依赖越少。其他的高密度部署、敏捷交付、微自治，暂时没体验过。
总结
了解历史的演进过程，才能清楚自己所处哪个潮流中。该如何在这个技术迭代的浪潮中该如何去选择学习的重点技术。而不是人云亦云的去追逐。个人感觉，跟计算机网络的发展有点类似。从单台计算机到局域网，局域网到广域网。从局域网的CSMA/CD协议，到广域网的点对点协议（PPP协议）。
