互联网始于 1969年美国的阿帕网(ARPA),最开始的阿帕网只在美国军方使用。随着时间的推移,一些大学也开始加入建设,慢慢演化成了现在的因特网 (Internet)。随着计算机网络的普及,到现在全世界几乎一半的人口,都在使用互联网产品。日常生活中的各种场景,如商场购物、沟通交流、金融理财、货运物流等,都可以在网上实现。随着网上的应用越来越多,用户也越来越多,业务场景也越来越复杂,传统的单体应用已经无法满足互联网技术的发展要求。随着业务复杂度的逐渐提升,代码的可维护性、可扩展性和可阅读性在逐步降低,修改和更新代码的风险也变得越来越高。而技术作为业务的支撑,它永远伴随着业务的发展而发展,所以为了解决单体应用的缺点,诞生了微服务。
最近几年,微服务很受欢迎,无论是在公司的实际开发应用中,还是在技术人员之间的日常话题交流中,微服务的技术都是主流。微服务概念是著名的 IT 专家 Martin Fowler提出来的,它是用来描述将软件应用程序设计为独立部署服务的一套思想,一般按照业务进行服务划分,它有自动化运维、容错、快速迭代的特点,给软件领域带来了巨大的影响。
那么,微服务是怎么一步一步演进到现在的?在实际生产开发中,如何正确使用微服务呢?这些问题一定要先搞清楚,否则做微服务项目,就会做成大型的分布式单体应用。
要知道任何技术和方案的形成都不是一蹴而就的,很多思想、解决方案都是在原有理论的基础上进一步发展的。因此我们先来回顾一下软件架构的发展历程,了解这些知识会对以后的架构选型有很大的帮助。
在传统的软件架构中,经常提到 MVC(model-view-controller)模型,也就是模型视图控制器。即
M(model)数据访问层、V(view)视图层、C(controller)业务逻辑控制层。
开发服务端的软件一般都是按照 MVC架构来设计的,其主要功能包括响应用户的交互、对业务流程的操作、对数据库的增删改查。虽然有三层模型的划分,但这只是在软件架构上的分层,并没有对业务场景进行划分。一个单体系统就是将所有业务场景的视图层、业务逻辑控制器层、模型层全部囊括在一个工程内,所有的功能都在一个项目中开发,开发完成后打成jar 包,或者war 包,最终部署到一台服务器上。单体应用架构如下图所示。
在互联网早期,由于业务比较简单,访问量比较少,开发人员采用单体应用会有很多优点,下面从开发、测试、部署运维的角度分别进行分析。