首先我们在了解SpringCloud之前要明确两个概念，什么是单体结构，什么是分布式结构，什么又是微服务结构。对于这些问题我们来聊一聊项目结构的演变
一：项目结构的演变：
随着互联网迅猛的发展，项目需求增多，项目体量增大的情况，传统的项目结构不能满足当下需求，这个时候项目的结构就得到发展和演变：从最开始的单体项目演变到分布式项目再到如今的微服务架构，网格服务等，那我们来聊一下这些架构的特点，从而对这些项目选型有一个明确的了解和认识。
1.什么是单体项目：
简单概况就是将各个功能模块写在一个项目应用中，再将项目打成war包部署到一个tomcat上，这个就是一个单体项目。通常这个项目应用使用一个数据库。我们之前会将整个项目分成：业务层，表现层，持久层三个方面。在项目之处这样的项目架构没有任何问题，但是当项目维护时间过长，项目体量过大，伴随着的问题将慢慢浮现出来。
1.2 单体项目的特点：
缺点/问题：
- 当项目体量过大，开发时间过长，我们项目中的代码将过于冗余臃肿，维护困难大。
- 功能模块扩展性不高
- 单体项目对高并发的支持不是很好
- 如果项目中的某一个模块并发量过大，没有办法做单一模块集群处理
- 项目选型单一：如项目A模块是用java写的，其他模块就不能使用其他语言
- 项目耦合度高
2.什么是分布式架构：
可以按照业务功能将一整个应用拆分成多个小的应用，多个小应用部署在不同的服务器中，每一个应用都是一整套系统，每一个子系统互相通信互相协调一起工作完成一个完整的工作流程。简单的说就是多个人分工作业，一起工作，完成一件完整的事情。有点像0.5加0.5等于1的意思
3.什么是微服务架构：
微服务架构可以认识是在SOA架构上的一种发展，最早由“Martin Fowler”提出：
就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。但通常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。
另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。
从上述描述中可以看到，微服务架构就是将整个应用按照业务拆分成多个服务，每个服务独立运行，每个服务只关注自己的业务即可，并且每一个业务拥有自己的数据库(分库)，服务之间互相通信互相协调完成一个完整的业务。
3.1微服务架构的特点：
特点：
- 由多个服务组成一个完整的系统
- 服务之间采用http请求方式进行通信
- 每个服务有独立的进程
- 不同的服务之间可以使用不同的语言
- 不同的服务之间可以使用不同的数据库
- 微服务是一种分布式系统
3.2微服务的优缺点：
优点：
- 每个服务只需关注自己的业务即可，新手上手快
- 可以对单个业务做集群处理
- 技术选型丰富
- 单个服务业务简单，维护方便
- 服务之间低耦合，互相升级不影响
缺点： - 服务通信机制造成了事务的复杂性，需要合理选择事务方案(CAP)
- 项目部署麻烦，微服务众多，部署成本高
- 增加技术人员的学习成本
- 服务之间使用http协议，与单体项目来说对性能有一定损耗
3.3如何进行技术选型：
那么就会有人问单体项目和微服务项目到底该怎么去选或者哪个更有优势
虽然微服务相对于单体项目有很多优势，那么是不是什么项目都适用于微服务呢?很显然不是的，这个要看项目的体量有多大，就像你只做一个简单的后台系统，如果你使用微服务去做这个就有点大材小用而且会浪费很多性能。所以说能用单体项目就使用单体项目，当项目足够大，单体项目满足不了需求就是要使用微服务架构。下图是单体项目和分布式项目的性能分析图：
4.总结
通过这篇文章我们了解到了微服务只是一个思想，一种架构模式，我们是需要通过某种技术实现这个思想，那么SpringCloud就是这个思想的实现。
下一章我们会继续聊一聊SpringCloud常用组件，我们是如何实现微服务的。感谢大家的支持