【架构】Java 系统架构演进的思考

1 前言

随着移动互联的发展，网站、H5、移动端的应用规模也不断扩大，不管是应用的数量还是质量都得到了指数级的提升。开发者的数量与日俱增，应用的复杂度也在不断提高，如何快速的完成功能的交付，并且协调众多的开发者一起进行分工合作，这是一个复杂的系统工程。互联网从萌芽到现在，系统架构大体经历了几个过程：单体应用架构、垂直应用架构、分布式架构、SOA架构、微服务云架构。在本文中，将介绍架构的演进过程以及自己的思考。

2 单体应用架构

在互联网发展的早期，其网站应用的流量较小，所有的功能代码以及数据存储都是一台服务器之上，这样的做法可以减少开发、部署和维护项目的成本。在这个阶段，一般都是前后端不分离的阶段，一个 tomcat 下部署多个应用服务。常见的技术栈包括 spring+mybaits+jsp 或者 spring+mybaits+freemaker。该种方式的优点是单人维护，开发节奏快，缺点是不适合大型项目，模块之间耦合较大，单点容错率低。

3 垂直应用架构

垂直应用架构出现的背景是网站的访问量越来越大，单一应用还可以增加节点来应对，但是并不是所有的模块都需要增加服务能力，所以需要对服务按照功能进行拆分，对用户访问量大的模块进行扩容。系统的拆分分担了流量，解决了并发的问题，还可以针对不同的功能模块进行分工和优化，此外一个系统的问题不会影响其它的系统，提高了系统间的容错率，这是垂直应的优点，同时各个系统之间无法调用，会存在重复的功能代码，另外对于管理系统来说，session 的会话保持也是一个巨大的问题，这种模式下，一般采用 tomcat session 复制的模式，对资源的消耗比较大。

4 分布式架构

在分布式系统中，会将系统中重复的代码单独抽离出来作为独立的服务，原来的垂直系统分成了独立的服务层和具体业务的展现层，该种架构下提高了代码的复用性，但是系统间的复杂度和耦合度增加，项目维护难度较大。

5 SOA 架构

对于 SOA 架构，就是在分布式的架构基础之上引入了一个服务注册中心，用来解耦展现层和服务层，极大的解决了系统的运维难度。在 SOA 的架构下，ssm 框架 + dubbo + zk 的结构可谓是风靡一时。在 SOA 的架构下，服务进一步的拆分，可以尽可能的发挥人员的效力，在此种架构下，同时也实现了前后端的分离，使得开发效率进一步的提高，后端和前端都各自专注于自己的领域，系统的复杂度进一步提高。

6 微服务云架构

在万物互联，万物上云的时代，微服务的架构应运而生。微服务的架构进一步的拆分服务，并引入各种系统组件，用于服务治理，服务监控，链路追踪，鉴权与授权。在此种场景下，各个服务组件更加专业化，不仅仅是服务的注册与发现，还有配置中心，链路追踪等，微服务全家桶（springcloud springcloud alibaba）。
SOA 的架构与微服务的架构服务能力对比：

SpringCloud 各个组件可选的技术方案。

7 总结

在本文中，主要介绍了是近10年来服务架构的演进路径，以及每一种架构的优点和缺点。现在是万物互联，万物上云的时代，微服务是目前十分流行的大型项目的解决方案。但是在实际的项目开发中，也要考虑实际情况，要考虑项目的定位和发展情况不能过度开发，最流行的解决方案不一定是最好的，而是要选择与业务场景最适配的架构，这样才可以保证项目的交付与迭代更新。