Spring Cloud与微服务构建（一）微服务简介 1.1 单体架构及其存在的不足

随着互联网技术的飞速发展，目前全球超过一半的人口在使用互联网，人们的生活随着互联网的发展，发生了翻天覆地的变化。各行业都在应用互联网，国家政策也在大力支持互联网的发展。随着越来越多的用户参与，业务场景越来越复杂，传统的单体架构已经很难满足互联网技术的发展要求。这主要体现在两方面，一是随着业务复杂度的提高，代码的可维护性、扩展性和可读性在降低；二是维护系统的成本、修改系统的成本在提高。所以改变单体应用架构已经势在必行。另外，随着云计算、大数据、人工智能的飞速发展，对系统架构也提出了越来越高的要求。
微服务，是著名的OO（面向对象，Object Oriented）专家Martin Fowler提出来的，它是用来描述将软件应用设计为独立部署的服务的一种特殊方式。最近两年，微服务在各大会议、文章、书籍上出现的频率已经让人们意识到它对于软件领域所带来的影响力。微服务架构的系统是一个分布式系统，按业务领域划分为独立的服务单元，有自动化运维、容错、快速演进的特点，它能够解决传统单体架构的痛点，同时也能满足越来越复杂的业务需求。

1.1 单体架构及其存在的不足

1.1.1 单体架构简介

在软件设计中，经常提及和使用经典的3层模型，即表示层、业务逻辑层和数据访问层。

-表示层:用于直接和用户交互，也称为交互层，通常是网页、UI等。
-业务逻辑层：即业务逻辑处理层，例如用户输入的信息要经过业务逻辑层的处理后，才能展现给用户
-数据访问层：用于操作数据库，用户在表示层会产生的数据，通过数据访问层对数据库进行读写操作。
虽然在软件设计中划分了经典的3层模型，但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。例如典型的J2EE工程，它是将表示层的JSP、业务逻辑层的Service、Controller和数据访问层的Dao，打成war包是，部署在Tomcat、Jetty或者其它Servlet容器中运行。

在一个小型应用的初始阶段，访问量较小，应用只需要一台服务器就能够部署所有的资源， 例如将应用程序、数据库、文件资源等部署在同一台服务器上。最典型的就是LAMP系统，即服务器采用Linux系统，开发应用程序的语言为PHP部署在Apache服务器上，采用MySQL数据库。在应用程序的初始阶段，采用这种架构的性价比是非常高的，开发速度快，开发成本低，只需要一台廉价的服务器。

1.1.2 单体架构存在的不足

在应用的初始阶段，单体架构无论是在开发速度、运维难度上，还是服务器的成本上都有着显著的优势。在一个产品的前景不明确的初始阶段，用单体架构是非常明智的选择。随着应用业务的发展和业务复杂度的提高，这种架构明显存在很多的不足，主要体现在以下3个方面。

• 业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降，新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。
• 随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
• 测试的难度越来越大，单体应用的业务都在同一个程序中，随着业务的扩张、复杂度的增加，单体应用修改业务或者增加业务或许会给期货业务带来一定的影响，导致测试难度增加。

1.1.3 单体架构使用服务器集群及存在的不足

随着业务的发展，大多数公司会将单体应用进行集群部署，并增加负载均衡服务器（例如Nginx等）。另外，还需要增加集群部署的缓存服务器和文件服务器，并将数据库读写分离，以应对用户量的增加而带来的高并发访问量。
用负载均衡服务器分发并发的网络请求，用户的访问被分派到不同的应用服务器，应用服务器的负载不再成为瓶颈，用户量增加时，添加应用服务器即可。通过添加缓存服务器来缓解数据库的数据以及数据库读取数据的压力。大多数的读取操作是由缓存完成的，但是仍然有少数读操作是从数据库读取的，例如缓存失效、实时数据等。当有大量的读写操作时，将数据库进行读写分离是一个不错的选择，例如MySQL的主从热备份，通过相关配置可以将主数据库服务器的数据同步到从数据库服务器，实现数据库的读写分离，读写分离能够改善数据库的负载能力。
这种架构有一定的处理高并发的能力，也能应对一定复杂的业务需求，改善了系统的性能，但是依然没有改变系统为单体架构的事实，此时存在的不足之处如下。

• 系统仍然为单体应用，大量的业务必然会有大量的代码，代码的可读性和可维护性依然很差。
• 面对海量的用户，数据库将会成为瓶颈，解决方案将使用分布式数据库，也就是将数据库进行分库分表。
• 持续交付能力差，业务越复杂，代码越多，修改代码和添加代码所需要的时间越长。新人熟悉代码的时间长、成本高。

由此可见，在应用初期，单体应用从成本、开发时间和运维等方面都有显示有优势。但在随着业务量和用户量的增加，它所暴露出来的缺点也显而易见。单体架构已经不能满足复杂的业务和海量的用户系统，改变单体架构势在必行。