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