（一）SpringCloud学习之微服务架构演变过程及微服务的一些概念（拉勾网为例）
工作了几年，一直想找机会系统学习一下Java高级知识，最近参加了拉勾教育Java工程师高薪训练营已有三个月了，每天除了上班都是学习，这样的日子让我每天不仅不感到累，反而十分兴奋和开心，因为拉勾的课程量非常之多（所以是很划算的）且质量很高。比如Spring Cloud学习，老师结合拉勾网自身的架构演变，充分的分析了互联我那个架构从单体架构到微服务的演变过程，已经微服务的一些基本概念，图文结合，及生动形象的例子讲解，，以及后面的实战和最后课后作业强化，让我们快速并准备的掌握这些只是以及应用场景及实战。以下是一些学习笔记的记录。
1.1、互联网应用架构发展
随着互联网发展，用户群体日益增长，网站流量也是不断增长。常规单体架构无法承受住请求压力和业务快速迭代，架构演变称为了势在必行之事。下面以拉勾网架构演变过程为例。
1.1.1、单体应⽤架构
在诞生之初，拉勾用户数量及规模都比较小，所有功能都在一个工程中，并且部署在一个Tomcat容器的架构模式中。这样的架构就是单体架构。这样的架构即简单又便于维护，成为那个时代主流
优点
项目前期开发节奏快，架构简单，易于测试和部署
缺点
-
随着不断功能迭代，单个项目过大，代码杂乱，耦合严重。
-
开发团队扩容后，沟通成本变高。
-
新增业务困难
-
核心业务与边缘业务混合在一块，出现问题相互影响
业务上涨后，单体架构进一步演化，比如应用集群，使用nginx负载均衡，增加缓存服务器，则见文件服务器，数据库集群并做读写分离等。通过这些措施应对高并发的能力但依然属于单体架构。
1.1.2、垂直应用架构
为了避免上面问题，开始做模块的垂直划分，也就是根据业务特性，将项目拆分为多个子系统分开部署。
优点
-
系统拆分实现类流量分担，解决了并发问题
-
可以针对不同模块进行优化
-
方便水平扩展，负载均衡，容错率提高
-
系统间相互独立，互不影响，新业务迭代更高效
缺点
-
服务之间调用通过硬编码方式
-
搭建集群后，负载均衡比较复杂，如内网负载，迁移机器时会影响调用方的路由，导致线上故障等
-
服务之间调用方式不统一，可能是httpClient, WebService等接口协议不统一
-
服务监控不到位：除了依靠端口，进程监控，用成功率、失败率、总耗时等监控指标是没有的
1.1.3、SOA应用架构
垂直划分后，随着模块越来越多，维护成本也越来越高。一些通用业务和模块重复越来越多。为了解决上面接口协议不统一，服务无法监控，服务负载均衡复杂等问题，引入Apache dubbo，一款高性能、轻量级的开源java rpc框架。它提供了三大核心功能：面向接口的远程调用，智能容错和负载均衡，以及服务注册与发现。
优点
-
服务以接口为粒度，为开发者屏蔽远程调用细节
-
业务分层后架构更加清晰，每个业务模块职责单一，可扩展性强
-
数据隔离，权限回收，数据访问通过接口 让系统更加稳定安全
-
服务本身无状态化，指不做内存级缓存，二是把数据存入db
缺点
-
粒度控制复杂，如果没有控制好，服务模块越来越多，就会引发超时 分布式事务等问题
-
服务接口数量不宜控制 容易引起接口爆炸 建议根据业务场景单位划分，并对相近业务做抽象 防接口爆炸
-
版本升级困难
-
调用链路过长的话 服务的质量不可监控 比如下游抖动会影响上游业务 最终形成连锁反应
1.1.4、微服务应用架构
微服务架构可以说是SOA的一种扩展，这种架构拆分粒度更小、服务更独立。吧每个应用拆分为一个个微小的服务，不同服务可以使用不同的开发语言与存储，服务之间往往通过restful等轻量级通信。微服务在于微小、独立、轻量级。
微服务架构与SOA架构相似又不同
很明显的一个区别就是拆分粒度不同。
1.2、微服务架构思想及优缺点
微服务的核心思想就是"微"，拆分的粒度相对⽐较⼩。
微服务架构优点
-
微服务很小，便于特定业务功能的聚焦
-
微服务很小，每个微服务都可以被一个小团队单独实施(开发，测试，部署上线，运维)，团队合作一定程度解耦，便于实施敏捷开发
-
微服务很小，便于重用和模块之间的组装
-
微服务很独立，不同微服务可以使用不同语言开发，松耦合
-
微服务架构下，我们更容易引入新技术
-
微服务架构下，我们可以更好的实现DevOps开发运维一体化
微服务架构缺点
-
微服务架构下，分布式复杂难以管理，服务增多，管理就会更复杂
-
微服务架构下，分布式链路追踪难等
1.3、微服务架构中的一些概念
1.3.1 服务注册与发现
服务注册：服务提供者将提供服务的信息(IP/端口/协议等)注册/登记到注册中心
服务发现：服务消费者从注册中心获取较为实时的服务提供者列表，然后根据一定策略选择一个服务访问
1.3.2 负载均衡
负载均衡即将请求压力分配到多个服务器，来提高服务器的性能、可靠性
1.3.3 熔断
熔断即断路保护。微服务架构中，下游服务访问压力过大而相应过慢或者失败，上游服务为了保护系统整体可用性，可以暂时切断对下游服务的调用，返回一个兜底数据(预设的返回值)。这种局部牺牲，保全整体的措施叫做熔断。
1.3.4 链路追踪
微服务中，一个项目通常是多个服务，一次请求就需要涉及到很多个服务。所谓链路追踪，就是对一次请求涉及的多个服务链路进行日志记录、性能监控。
1.3.5 API网关
微服务中，不同微服务通常会有不同的访问地址，客户端需要调用多个服务接口才能完成一次业务请求，这样存在了一些问题。
-
客户端调用不同的url,增加维护成本
-
在一定场景下，存在跨域问题（如：前后端分离）
-
每个微服务都需要单独进行身份认证(如：登录认证)
Api网关就可以较好的同一处理上述问题。请求同一发送到API网关，由网关转发请求。
Api网关更专注在安全，路由，流量等问题上，它的功能可能如下：
-
统⼀接⼊（路由）
-
安全防护（统⼀鉴权，⽹关访问身份认证验证等）
-
黑白名单（实现通过IP地址控制禁⽌访问⽹关功能，控制访问）
-
协议适配（实现通信协议校验、适配转换的功能）
-
流量控制（限流）
-
长短链路支持
-
容错能力（负载均衡）
1.4、SpringCloud是什么？
-
Spring Cloud是⼀系列框架的有序集合（Spring Cloud是一个规范），不重复造轮子，将很多成熟的服务框架组合起来，提供一套完整的分布式解决方案。
-
开发服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等
-
利⽤Spring Boot的开发便利性简化了微服务架构的开发（⾃动装配）
Netflflix搞了⼀套 Spring Cloud简称SCN， 也叫做第一代Spring Cloud
Spring Cloud 吸收了Netflflix公司的产品基础之上⾃⼰也搞了⼏个组件
阿⾥巴巴在之前的基础上搞出了⼀堆微服务组件,Spring Cloud Alibaba（SCA） 第二代Spring Cloud
1.5、SpringCloud解决什么问题？
Spring Cloud 规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的⼀些问题，⽐如微服务架构中的服务注册发现问题、⽹络问题（⽐如熔断场景）、统⼀认证安全授权问题、负载均衡问题、链路追踪等问题
1.6、SpringCloud核心组件及架构
Spring Cloud核心组件
Spring Cloud ⽣态圈中的组件，按照发展可以分为第⼀代 Spring Cloud组件和第⼆代 Spring Cloud组件。
Spring Cloud架构图
流程分析
-
注册中⼼负责服务的注册与发现，很好将各服务连接起来
-
API⽹关负责转发所有外来的请求
-
断路器负责监控服务之间的调⽤情况，连续多次失败进⾏熔断保护
-
配置中⼼提供了统⼀的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息
1.7、SpringCloud与Dubbo对比
Spring Cloud Netflix基于Http，效率没有Dubbo高，但是Dubb体系的组件不全，不能提供一站式服务。Spring Cloud Netflix真正提供了一站式解决方案，且背靠Spring大家族。
前些年Dubbo使用率高于Spring Cloud, 目前Spring Cloud在微服务解决方案中已有了非常好的发展趋势
1.8、SpringCloud与SpringBoot关系
Spring Cloud充分利用了SpringBoot的优势，让我们快速实现微服务组件开发。所以Spring Boot是我们快速把Spring Cloud微服务技术应⽤起来的⼀种⽅式。
1.9 总结
拉勾网的课程真的让我真正的理解了很多比较深奥难懂的东西，当老师结合实际场景和图分析后讲出来却是那么容易让人理解。很多同学们学习也是叫一个巨快，所以自己也不能落下，于是每天学习就成为了我的日常。并且每天可不是简单进步一点点，而是每天都进步很多，并且和之前的知识点可以关联起来，掌握很多知识并且能够应用。所以该可能之好也就不再多说，在这里简单记录一些学习的点滴，希望后面能够早日找到心仪的工作。