微服务入门学习：SpringCloud、SOA、集群、分布式学习

什么是微服务

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

由于业务间的逻辑越来越复杂，我们就不把这些业务全部杂糅在一起，每个业务都分开来做，这就是微服务，而微服务就是一种特殊的分布式。

优缺点：

优点：上面的单体系统全部运行于一个进程之内，资源相互影响，添加功能可能会影响其它功能，导致维护麻烦。 而微服务一切分为不同的模块，运行于自身进程内，而且不同的服务可以使用不同的语言充分发挥优势。

缺点：引入了分布式的复杂性，如接口一致性。 不过很多问题强大的Spring Cloud都已经提供了解决方案！

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

什么是SOA呢？

SOA是什么 面向服务的架构

• 简单的来说：SOA不是什么具体的技术，是一种开发项目的思想，这种思想开发的项目有很多的好处。十分符合现在互联网迅速开发的时代。
• 进行一些简单点的举例说明：
• 设计：现在有一个数据库，一个JavaWeb（或者PHP）的网站客户端，一个安卓App客户端，一个IOS客户端，现在要给用户提供一个注册账号的功能。
• 不使用SOA的设计思想的实现：JavaWeb里面写一个注册账号的功能，安卓里面写一个注册账号，IOS也是，那么这样实现有没有什么问题呢？如果有一天需要改动注册方法，那么这三个地方都需要改动，并且需要改的一模一样，而且可能面临的问题会比这个多得多。
• SOA的设计思想的实现：用JAVA或者其他语言，单独创建一个工程部署在一台服务器上，并且写一个方法（或称函数）执行上述注册操作，然后提供一个接口，其他人可以通过某种途径（可以是http链接，或者是基于socket的RPC调用）访问这个方法来注册。就是说把这个操作封装到一个工程中去，然后暴露访问的方式，形成“服务”。要修改关于注册用户的业务方法只要改这个服务就好了，很好的解耦。类似设计模式中的单一职责原则，这样有什么好处呢？

扩展方便：一旦哪天突然有一堆人要注册，假设这堆人仅仅只是注册而不做其他事情，注册这个功能压力很大，而原有的一台部署了注册服务的服务器已经承受不了这么高的并发，这时候就可以单独集群部署这个注册服务，提供多几台服务器提供注册服务。

语言通用：实现这个服务的可以是任何语言，只要提供的接口通用就可以了，比如PHP擅长处理逻辑、Ruby语言擅长高并发、java擅长大数据等那我可以再比如某些业务逻辑很复杂的服务中使用PHP，在某些并发很高的服务中使用Ruby。

新人友好：新人进公司的时候他无需了解整个项目的架构是怎样的，比如你进阿里了，你想要熟练整个淘宝的架构你会累死，而这种SOA思想开发的项目由于是服务形式的，比方把你分到购物车组，那你只需要了解购物车的功能就好了。

发版方便：比方说你是淘宝购物车项目组的，你的项目改了一些东西要发版（发布生产），如果你是传统项目测试可能怕你改动到了其他的东西影响到了其他的功能（虽然你很确信没改动到，但万一呢？）不得不对淘宝整体的功能都做一遍测试，累死人，而这种形式的测试只需要测试你的购物车的功能，so easy。退一步说，万一你改的代码有问题测试没测出来，那也是影响购物车的功能，用户下单支付不影响。

说完了好处下面来说说坏处

问题排查不便：比方用户买东西的时候出现了一个报错，很难直接定位到问题出在哪个环节，可能是订单组的代码有问题，也可能是支付组的代码有问题。

沟通不便：如果你们在大公司待过的话就会明白，用户组，订单组，购物车组，支付组等等是分别属于不同的领导管理，出了问题沟通起来很麻烦，甚至你都不知道找谁沟通，也能以前跟你沟通的人后来离职了等等的问题。

性能问题：相对于传统项目的直觉调用，SOA中不管你是使用RPC还是什么HTTP等技术调用，肯定会有性能的损耗，因为网络通信是需要时间的。

关系混乱：当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱。

运维难度：随着服务的增多，系统架构会越发复杂，这就给运维层面带来了挑战。 数据一致性问题：单体项目因为数据都在同一个数据库里面，不需要过多的关注分布式事务等问题，SOA就需要关心了。

整体而言SOA肯定是利大于弊的，虽然缺点很明显，但是基本都是可以克服的，问题排查不便那就对花点时间差呗，沟通不便就找上级领导多沟通呗，性能问题用内网什么的也能降低到很少，关系乱就可以用服务治理。相对而言好处部分基本上是不可能克服的，比如非SOA项目扩展基本很难，全部的代码丢到一个项目里面类似淘宝这种新人可能看三年五年也看不懂。

服务治理

就是当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱，需要对这些关系进行管理。举例，还是上面的例子，假如我有一个用户服务，一开始有调用方1和调用方2来使用这个服务，后来越来越多，将近上百个调用方，这个时候作为服务方，它只知道提供服务，却不知道具体为谁提供了服务。而对于开发者来说，知道这N多调用方和N多服务方之间的关系是非常重要的。所以这个时候就需要能进行服务治理的框架，比如dubbo+zookeeper，比如SpringCloud，有了服务治理功能，我们就能清晰地看到服务被谁谁谁调用，谁谁谁调用了哪些服务，哪些服务是热点服务需要配置服务器集群，而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。

SOA总结

实际上SOA只是一种架构设计模式，而SOAP、REST、RPC就是根据这种设计模式构建出来的规范，其中SOAP通俗理解就是http+xml的形式，REST就是http+json的形式，RPC是基于socket的形式。CXF就是典型的SOAP/REST框架，dubbo就是典型的RPC框架，而SpringCloud就是遵守REST规范的生态系统。

分布式与集群、微服务

集群可以说是个物理形态，而分布式是个工作方式。

简单理解：

分布式：一个业务分拆多个子业务，部署在不同的服务器上

集群：同一个业务，部署在多个服务器上

一句话，就是：“分头做事”与“一堆人”的区别

集群

• 单机结构：我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。

那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式，往下接着看。

• 集群结构： 单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。

但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。

集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用微服务结构了。

一般来说集群分为以下几类：

从单机结构到集群结构，你的代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议，系统设计之初就采用微服务架构，这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深思熟虑、权衡投入产出比。

分布式与微服务

分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。一个系统分为很多个子系统，这些子系统相互配合完成整个的业务逻辑叫做分布式，分布式中每一个节点都可以配置集群.。

举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。

微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

而微服务和分布式的区别如下是：

1.微服务是一种特殊的分布式

2.区别及联系

微服务：分散能力。分布式：分散压力。

分布式：

不同模块部署在不同服务器上;

作用：分布式解决网站高并发带来问题;

集群：相同的服务;

多台服务器部署相同应用构成一个集群;

作用：通过负载均衡设备共同对外提供服务;

SOA［组装服务/ESB企业服务总线］：

业务系统分解为多个组件，让每个组件都独立提供离散，自治，可复用的服务能力;

通过服务的组合和编排来实现上层的业务流程;

作用：简化维护，降低整体风险，伸缩灵活;

微服务［找到服务/微服务网关open API］;

架构设计概念，各服务间隔离（分布式也是隔离），自治（分布式依赖整体组合）其它特性（单一职责，边界，异步通信，独立部署）是分布式概念的跟严格执行;

SOA到微服务架构的演进过程;

作用：各服务可独立应用，组合服务也可系统应用（巨石应用［monolith］的简化实现策略-平台思想）.

SpringCloud是什么

简单来说，Spring Cloud是一个微服务框架的规范，注意，只是规范，他不是任何具体的框架。我们知道java大佬最喜欢的做法就是自己制定规范，然后别人基于我这个规范来做实现。那么这个规范里面有什么呢，它规定大概要有以下几种功能。

1、服务的注册与发现 2、负载均衡 3、服务熔断和限流 4、智能路由 5、控制总线 6、链路监控

刚好，这个时候有一个框架集合几乎能满足上面所有的需求，他就是Spring Cloud Netflix。当然，Spring Cloud的实现产品不止这一个，还有最近由阿里新起的Spring Cloud Alibaba等。目前国内主流的是Spring Cloud Netflix。也是接下来介绍的主角。

在SpringCloudNetflix之前，可以先了解Netflix公司。 1、首先，Netflix是一家做视频的网站，可以这么说该网站上的美剧应该是最火的。 2、Netflix是一家没有CTO的公司，正是这样的组织架构能使产品与技术无缝的沟通，从而能快速迭代出更优秀的产品。在当时软件敏捷开发中，Netflix的更新速度不亚于当年的微信后台变更，虽然微信比Netflix迟发展，但是当年微信的灰度发布和敏捷开发应该算是业界最猛的。 3、Netflix由于做视频的原因，访问量非常的大，从而促使其技术快速的发展在背后支撑着，也正是如此，Netflix开始把整体的系统往微服务上迁移。 4、Netflix的微服务做的不是最早的，但是确是最大规模的在生产级别微服务的尝试。也正是这种大规模的生产级别尝试，在服务器运维上依托AWS云。当然AWS云同样受益于Netflix的大规模业务不断的壮大。 5、Netflix的微服务大规模的应用，在技术上毫无保留的把一整套微服务架构核心技术栈开源了出来，叫做Netflix OSS，也正是如此，在技术上依靠开源社区的力量不断的壮大。 6、Spring Cloud是构建微服务的核心，而Spring Cloud是基于Spring Boot来开发的。 7、Pivotal在Netflix开源的一整套核心技术产品线的同时，做了一系列的封装，就变成了Spring Cloud；虽然Spring Cloud到现在为止不只有Netflix提供的方案可以集成，还有很多方案，但Netflix是最成熟的。

• 那么Spring Cloud Netflix有哪些组件呢？

1、eureka (提供服务注册与发现功能) 2、ribbon（提供负载均衡功能） 3、Feign（整合了ribbon和Hystrix，具有负载均衡和熔断限流等功能） 4、Hystrix （提供了熔断限流，合并请求等功能） 5、Zuul （提供了智能路由的功能） 6、Hystrix Dashboard （提供了服务监控的功能，提供了数据监控和友好的图形化界面） 7、Hystrix Turbine （Hystrix Turbine将每个服务Hystrix Dashboard数据进行了整合。也是监控系统的功能） 8、spring cloud config （提供了统一配置的功能） 9、Spring Cloud Bus （提供了配置实时更新的功能）

需要注意的是这些组件并不是一体化的，比如你完全可以用携程的Apollo来替换spring cloud config。也可以用NCOS或者Zookeeper来替换eureka.

Spring Cloud和Spring boot的关系

与其说他们有什么关系，不如说他们就没有什么关系。只是现在微服务当道，而实现一个服务最快的办法就是用spring boot。不然你还要自己搭项目自己找jar包自己搞配置，还有兼容性等情况。那你的服务化进程注定是缓慢的。所以他们之间是没有关系的，只是因为微服务所需要的小应用很多，而spring boot恰恰又是实现小应用最快的方式。

Spring Cloud和dubbo的关系

dubbo是阿里搞得一套框架，是基于RPC调用的，而Spring Cloud Netflix是基于HTTP的，所以效率上应该dubbo更快（如果你不能理解什么是RPC，当我没说，反正dubbo更快就是了）。但是dubbo的组件不是很齐全，他的很多功能比如服务注册与发现你需要借助于类似zookeeper等组件才能实现，而Spring Cloud Netflix则是提供了一站式解决方案。从使用广度来说，在国内几年前dubbo的使用人数远多于Spring Cloud的，但是近来Spring Cloud慢慢的有了后来居上的趋势。

• RPC是什么：
• Remote Procedure Call远程过程调用，他是一种通过网络从远程计算机上请求服务，而并不需要了解底层网络技术的协议。
• RPC协议假定某些传输协议的存在，如TCP或者UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
• RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。
• Restful和RPC是什么关系：这两个不是互斥的，HTTP是不是RPC完全取决于client的具体形式。传统的RPC一般是基于二进制协议的，client发个二进制包过来（然后阻塞），server处理完回复一个包，client收到后醒来。在二进制协议中一般可以在包中加个id来指明回复和请求的对应关系，这样我们就能在一个tcp连接上同时发起多个请求和回复。HTTP这种文本协议也可以加id，但由于一些原因（Content-Length可能缺失），即使加了id也做不到一个连接上同时传多个HTTP消息，所以HTTP协议一般会和server保持多个连接，每个连接上同时最多只有一个HTTP消息。此种”连接池“方式即为HTTP中的”Keep-alive“。所以即使在HTTP上（或任何协议上），我们仍然可以做到高效地发送一个请求过去，阻塞，等待server处理完后，再醒来。这不就是RPC么。所以这儿的选择更多是平衡功能和性能。一般来说，面向终端用户的尽量用Restful HTTP。原因是认知广，直观，编程语言都支持HTTP（包括shell，这样调试起来方便），性能不是那么重要，方便用户share链接。而面向内部系统的话如果机器不多也可以考虑用Restful HTTP，如果机器很多还是尽量用二进制的RPC吧，毕竟性能差距还是很大的。

相关参考链接： https://blog.csdn.net/qq32933432/article/details/89918264

https://blog.csdn.net/weixin_42254857/article/details/82624538

https://blog.csdn.net/qq_34395857/article/details/83780873

https://blog.csdn.net/qq32933432/article/details/87195037