在找.net core 微服务框架时发现了Steeltoe开源项目，它可以基于Spring Cloud实现.net core和.net Framework的微服务。正好之前也有学习过SpringBoot，而Spring Cloud是基于SpringBoot的，有了SpringBoot基础上手入门SpringCloud应该也不难，正好我的第一本书<<Spring快速入门>>即将上架，感兴趣的朋友可以多多支持。本篇主要学习服务注册与发现组件Eureka。
在学习之前首先聊一聊为什么会有微服务，它的优缺点是什么。
在微服务之前主要是单体应用，单体应用常见的就是一个war文件包含所有功能的应用程序包，每次迭代更新哪怕是更新一行代码都需要重新打包部署，同样每次迭代可能都要进行测试，模块与模块之间耦合度也比较高，导致可能需要对整个war包进行的测试，如果出现一个bug导致内存溢出，死循环，可能导致整个应用崩溃。二八原则在日常生活中普遍存在，在软件领域也一样，我们平时浏览网页一般读的多，写的少，例如逛博客园，我们可能浏览的比较多，提交数据的频率比较少，在单体应用中如果要增加浏览接口的部署，同样也会将提交数据的接口部署上去会造成资源浪费，单体应用往往使用统一的技术平台或方案解决所有的问题，开发语言和框架固定之后后续想引入新框架和技术也比较困难。
在单体应用中主要是面对单个应用的编程，而在微服务中主要是面对单个功能点的编程，将提供的功能点对外发布，这样其他地方可以不用关心具体用什么语言什么技术实现的，直接调用即可。而且每个功能点可以独立部署，是解耦的。假如某个接口调用增多，可以单独部署该接口应用，扩展性比较好。某个节点出现故障可以迅速让其他节点顶上，不至于整个应用不可用，容错性好，某个服务访问超出服务器承载时也可以进行限流，后续的CI、CD容器化也比较方便。同样有优点也有缺点，微服务会导致对外提供的接口增多，部署数量增多，服务治理带来新的挑战，A服务会调用B服务，B服务会调用C服务，如果A服务报错了，那是A服务导致的还是B、C服务导致的呢，而且对外提供服务的节点可能会有很多，那是哪个服务的哪个节点导致的呢？所以还需要微服务的链路追踪与排查。前面也提到微服务方便扩展，那什么情况下需要扩展，哪些服务节点需要扩展，这需要用数据说话，那就需要对服务进行监控，而且监控的参数指标和维度也是不一样的。
前面算是导语，下面切回正题，来学习服务注册与发现组件Eureka。每个站点都对外提供某些服务，有点类似家里赶集一样，有的卖家说卖衣服的，提供卖衣服的接口，有的卖家是卖拖拉机的，提供卖拖拉机的接口，每个卖家都是独立分散的，假如每个卖家都不在一个集市上，那买家可能需要先找到每个卖家住在什么地方，哪个村的叫什么名字，一般逛一家可能还没选到可是的，还要多逛几家，这样买家就要来回跑，那有了集市之后就不一样了，每个卖家都在集市上提供不同的服务，买家只要到固定的集市上找需要的服务即可，就和在没出现淘宝之前买东西需要到实体商店，有了淘宝之后只要输入淘宝网址就能找到不同商家提供的不同服务。Eureka就是有点类似淘宝的功能，它为服务提供者(卖家)提供了一个集中的平台，只要注册一下说明提供什么服务，服务消费者(买家)不用关心服务提供者在什么地方，直接调用就好了，是一个中心化的过程。
一、创建Eureka Server
1.引入依赖
SpringCloud使用Eureka也比较容易，创建SpringBoot项目时选中Eureka Server即可，它会在pom.xml中自动引入下面两个依赖，也可以自己添加。
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter</artifactId> </dependency> <!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-netflix-eureka-server --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency>