Java单体服务和集群分布式SpringCloud微服务的理解

单体应用存在的问题

1.随着业务的发展开发变得越来越复杂。

2.修改或者新增，需要对整个系统进行测试、重新部署。

3.一个模块出现问题，很可能导致整个系统崩溃。

4.多个开发团队同时对数据进行管理，容易产生安全漏洞。

5.各个模块使用同一种技术进行开发，各个模块很难根据实际情况选择更合适的技术框架，局限性很大。

6.模块内容过于复杂,如果有员工离职,需要很长时间才能完成工作交接。

分布式、集群

分布式：讲一个复杂的问题拆分成若干个简单的小问题，将一个大型的项目架构还分成若干个微服务来协同完成。（软件设计层面）。将1个庞大的工作拆分成若干个小步骤，分别由不同的让你完成这些小步骤，最终将所有的结果进行整合实现大的需求。

集群：一台服务器无法负荷高并发的数据访问量，那么就设置10台服务器一起分担压力，10台不够就设置100台或者1000台（物理层面）。很多人干同一个事情，来分摊压力。

微服务的优点

各个服务的开发、测试、部署都相对独立，比如用户服务就可以拆分作为一个单独的服务，而它的开发也不用依赖于其他服务，如果用户量很大，我们可以很容易的对其进行负载。

当一个新需求出现时，特别是在一个庞大的项目系统中，你要去考虑各方面问题，兼容性、影响度等等，而使用微服务则可以直接跳过这些废时又烧脑的环节。

使用微服务将项目进行拆分之后，各服务之间就消除了诸多限制，只需要保证对外提供的接口正常可用，至于使用什么语言、什么框架通通不用关心。

微服务的不足

上面我们提到微服务的拆分是基于业务的，不是我们随心所欲，想怎么拆就怎么拆，由谁来拆，怎么拆？给团队协作沟通带来了很多挑战。

当服务调用方需要使用某服务的接口时，首先需要找到该服务的提供方，通常在一个大公司中，这种场景是跨部门的，沟通成本可想而知，同时，如果服务的提供方需要对某个接口进行修改，也得和各个服务调用方进行沟通。

犹豫各个服务相互独立，他们的数据也是独立的。这就会带来一个问题，当调用多个服务接口来进行操作时，如何保证各个服务的数据一致性，这既是问题，也是难点。

为什么是SpringCloud

SpringCloud 完全基于SpringBoot，服务调用方法是基于RESTAPI，整合了各种成熟的产品和架构，同时基于SpringBoot也是的整体的开发、配置、部署都非常方便。

Spring系的产品集功能齐全、简单好用、性能优越、文档规范等等于一身，因此SpringCloud还是为服务架构中一个十分优越的实现方案。

服务治理的核心三部分组成：服务的提供者、服务的消费者、注册中心。

在分布式系统架构中，每个微服务在启动时，将自己的信息存储在注册中心，叫做微服务注册。

服务者从注册中心获取服务者提供者的网络信息，通过该信息调用服务，叫做服务发现。

SpringCloud 中服务治理使用的是Eureka来实现，Eureka是Netfix开源基于Rest的服务治理解决方案，SpringCloud集成了Eureka，提供服务注册和服务发现的功能，可以和基于SpringBoot搭建的微服务应用轻松完成整合，开箱即用，SpringCloud Eureka。

Spring Cloud Eureka

Eureka Server,注册中心

Eureka Client,所有要进行注册的微服务通过Eureka Client连接到Eureka Server,完成注册。