微服务Eureka 架构
一、微服务介绍
1）什么是微服务？
<1>什么是微？
狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。
<2>什么是服务？
一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。
《把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务》
微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
微服务的目的是有效的拆分应用，实现敏捷开发和部署 。
2）为什么使用微服务？
<1>大部分的开发者经历和开发过单体应用，无论是传统的 Servlet + JSP，还是 SSM，还是SpringBoot，它们都是单体应用
单体应用的缺点：
i)部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）
ii)改动影响大，风险高（不论代码改动多小，成本都相同）
iii)因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）
在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。
到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。
这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。
最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。
3） 微服务与SOA（面向服务的架构）区别
微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同
微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python编写的服务，他们是靠Restful架构风格统一成一个系统的
所以微服务本身与具体技术实现无关，扩展性强。
二、Eureka包含两个组件：Eureka Server 和Eureka Client
- Eureka Server 提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
- Eureka Client是一个java客户端，用于简化与Eureka Server的交互.
在应用启动后，将会向Eureka Server 发送心跳默认周期为30秒，如果Eureka Server 在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除（默认90秒）。
Eureka Server 之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server 都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。
