微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)

1.什么是落地SOA(面向服务架构)?

        SOA面向服务架构,是一种架构思想,是跨语言和平台的.SOA宗旨简单明了,根据项目服务完成架构搭建,以服务为基准点完成组件化和模块化.提供服务是项目的基本内容,其他的Controller层和View层,只是体现服务的一种形式而已,目标是服务.

        面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

        微服务的概念是14年由James Lewis与Martin Fowler共同提出的,他们定义了微服务是由单一应用程序构成的小服务,拥有自己的进程与轻量化处理,服务依业务功能设计(微服务一个业务一个项目),以全 自动方式部署,与其它服务使用HTTP API 通讯(每个项目都是一个标椎的web项目,不再像之前RPC项目分为provider和consumer)

2.什么是微服务?

        新的架构理念,把所有的应用:大型应用,分布式应用,SOA应用 拆解,拆解的极度细致,细致到拆成一个一个的单一的小应用,细致的程度:最细的应用可能就一个方法栈或者一个功能组.以一个方法栈来说:比如说一个电商后台商品新增,从控制器,到服务,到Mapper,到pojo 放在一起打成一个项目,这些项目控制器,服务.接口与接口实现,pojo,配置文件,环境.放在一起,达成一个包,形成一个小的应用,启动 ! 功能就一个方法栈---新增商品.以一个功能组来说:比如说商品后台的管理有:分页查询, 新增商品, 更新(修改)商品, 删除商品, 上架和下架商品 6种功能.这些项目控制器,服务.接口与接口实现,pojo,配置文件,环境.放在一起,达成一个包,形成一个小的应用,启动 !每个单一的小应用就是一个小服务,每个小服务都有自己独立的进程,进程内部自主进行线程规划管理.作为一个轻量化的服务对调用者而言没有任何的侵入.想调用服务,不需要接口,不需要任何的依赖,因为它是基于http协议调用的. 全自动方式部署,用docker做虚拟化开发,或者做打包部署,没有任何的配置,每个jar包就是一个项目,不用任何的环境,启动就完事了!可通过Docker虚拟化技术进行集中化管理,也可通过远程控制的方式集中化管理,(运维方面)自动部署平台集中管理.可跨语种开发.

2.1提出的核心点:

        1.微服务是架构 ;

        2.微服务中项目都称为服务 ;

        3.微服务拆分颗粒度为业务 ;

        4.微服务中服务与服务之间使用HTTP协议通信;

                (1).微服务目的在于微和跨平台,想把市面上的各种服务抽取出来 ,变成为服务,让所有的服务尽可能的不重复.比如说,一个专门做图片管理的运营商,买了很多的服务器,专门做图片管理,上传图片,在线查看图片,下载图片.任何一个开发的项目都可以买我的服务做图片管理,不管是用什么语言开发的,都可以用,以协议作为标准.

        5.微服务和Docker结合使用更方便

                (1).docker虚拟化技术,比如拿docker可以虚拟化一个JDK环境,你把你写好的代码放到我的环境里,我再把它打包成一个新的虚拟化工具,你拿走,放到任何地方,知道有docker环境,就可以运行.

        6.微服务是分布式架构的一种

                (1).RPC软件模型,SOA面向服务编程,微服务架构

2.2为什么使用微服务?

        单体应用的特点:大部分的开发者都开发过单体应用,无论是传统的Servlet+JSP ,还是SSM, 还是现在SpringBoot,他们都是单体应用,主要弊端原因如下:

                a).部署成本高(无论是修改1行代码,还是10行代码,都要全量替换);

                b).改动影响大,风险高(不论代码改动多少,成本都相同);

                c).因为成本高,风险高,所以导致部署频率低(无法快速交付客户端需求).

                d).无法满足快速扩容,弹性收缩,无法适应云环境特性等环境.

                注意: 单体应用虽然有上面的缺点,但是依然有自己的市场,如果项目规模比较小,办公类等不需要频繁修改版本的应用使用单体架构还是很方便的.

2.3微服务特点:

        针对特定服务发布,影响小,风险小,成本低;频繁发布版本,快速交付需求;低成本扩容,弹性伸缩,适应云环境等特点.

        微服务架构与现在企业中敏捷开发思想是匹配的,核心都是强调希望项目快速更新迭代(当项目需要快速更新迭代时微服务架构就特别合适)(这就是为什么使用微服务).

        我们知道一个朴素的概念,任何事物都不可能是完美的,任何东西都有两面性,有得必有失,那么选择微服务在解决了快速响应和弹性伸缩的问题的同时,他又给我们带来了什么问题呢?

2.4简单总结如下(微服务架构的缺点):

        1.分布式系统的复杂性;

        2.部署,测试和监控的成本问题;

        3.分布式事务和CAP的相关问题

        4.分布式中微服务架构相对于单体架构还需要处理很多事情.例如:分布式事务,团队合作等问题都需要明确的提前设计好.

3.应用架构的变迁: 应用向CloudNative演进, 微服务是CloudNative的事实标准

第一代: 单体架构;

• 紧耦合
• 系统复杂、错综交互 , 动一发而牵全身 .
• 重复制造各种轮子: OS、DB、Middleware
• 完全封闭的架构

第二代: SOA架构; 通过ESB中间件进行服务调用 ,是要有状态的,相对来说量级较重,效率较低

• 松耦合
• 通常通过ESB进行系统集成
• 有状态
• 大团队 :100 ~ 200 人
• TTM : 1年、半年 、月
• 集中式、计划内停机扩容

第三代: 为服务架构; 自洽(可以自己和自己玩) , 自省 (和外部可交互可不交互), 内聚(需要的代码都放在项目内部).独立访问,独立使用,独立运行. 多版本并行服务(比如游戏在线更新).整体来说 "自动化" .

• 解耦
• 小团队 : 2 Pizza Team\
• TTM: 按天、周进行升级发布
• DevOps : CI、CD、全自动化
• 可扩展性 : 自动弹性伸缩
• 高可用 : 升级、扩容不中断业务

3.1RPC架构和SOA架构和微服务架构的区别?

        SOA 架构 : 核心消息总线 . 消息总线过于杯中在目前的项目中已经很少使用了.

        RPC 架构 : 主要有被调用的远程服务器( Provider) 和调用的服务器 ( Consumer),把所有数据库操作都封装到了Provider. 一个单体拆分成多个,之间使用HTTP通信,每个项目又拆分成两个(Provider和Consumer),之间使用Dubbo协议通信,mapper和service 写到provider中,service和contorller写到consumer中.

        微服务服务架构: 每个业务是一个项目.业务之间通信使用HTTP通信协议,不再对一个业务(模块)项目进行拆分成Provider和Consumer了.mapper和service和controller都写到一个项目中.

3.2目前市场上微服务架构的常用实现框架:

        实现框架: SpringCloud.

        Spring Cloud Netflix : 市场上使用最多的.

        Spring Cloud Alibaba :基于Dubbo实现的.

        SpringCloud 里面目前包含三体体系:

        Spring 自己的 :为了摆脱受Netflix公司限制,所有功能都自己又逐渐推出一套.

4.1SpringCloud简介:

        Spring Cloud 是Spring旗下的一个顶级项目.他没有具体的内容,但里面包含了很多的二级子项目, SpringCloud就是这些二级子项目的统称.

        Spring Cloud包含了很多二级子项目,每个二级子项目都有对应的功能,所以S品牌日那个Cloud整体的包含的功能是比较强大.

        强调:SpringCloud是完全基于SpringBoot的,官方文档中就没有xml配置版本.

        Spring Cloud集成时会把Netflix的软件进行打包成一个依赖,我们的项目依赖了对应的jar,可以直接使用这个软件,免去了软件安装的过程(这也是SpringCloud非常大的优点).

4.2.SpringCloud 与Dubbo 的对比:

SpringCloud和Dubbo(SpringCloud Alibaba) 都是微服务开发框架.不是新的技术就一定是好技术.Dubbo优势在于开发简单,效率高.SpringCloud 优势在于功能全面且可靠性高.

4.3什么是是服务治理化?
        就是做服务开发的,简单粗暴地说,没有微服务的话,就是Provider ,Consumer开发,加了微服务开发,就是简单的微服务处理.

        服务注册中心:纯粹的Dubbo没有服务注册中心.

        服务调用方式:基于Dubbo的永远是远程调用RPC,SpringCloud 也是RPC,但是它底层协议单一:HTTP.Rest也是HTTP协议下的一套远程请求标椎.

        服务网关:Dubbo没有网关.

        4.3.1断路由是什么?

                就是容错处理.Dubbo容错处理简单粗暴,就是集群容错.说直接一点,远程调用:Consumer调用Provider,调用完了以后出错了,注意:这个出错不是抛异常,因为抛异常是有结果的.远程调用无响应,没有任何结果这是服务调用错误.当你的远程调用服务错误的时候,Consumer再调用一遍(重试),立即返回错误结果(超时),远程服务调用不存在,就当你这个服务没调用,