源码阅读环境搭建

• ide：IntelliJ IDEA
• 包管理：gradle
• eureka版本：1.9.13
• 源码下载：https://github.com/Netflix/eureka/archive/refs/tags/v1.9.13.zip

Eureka解决了什么问题

这个问题本质是问服务注册中心的价值。很多年前，那个时候微服务还没有兴起，大家用Nginx+Tomcat就搞定了，加机器加Tomcat时候，直接在线改Nginx配置就搞定，这叫手动服务注册。但是在现今的微服务架构中，服务可能动不动就几十个，上百个，算上冗余就几百个，而且微服务的发布很频繁，不断有新的服务加入进来；在应对大流量场景时，还需要扩容缩容。这如果还依靠Nginx那种原始的手工配置方式，是不可行的，成本太高了。所以，就出现了服务注册发现，即服务实例自己会在启动后注册到服务注册中心，这叫服务注册，然后每个服务实例又从服务注册中心拉取服务注册表，动态的感知到服务的上下线，这叫服务发现。所以，服务注册中心这种技术是在微服务架构中自然而然就过渡过来的，并不突兀。eureka作为Netflix全家桶中的服务注册中心实现，其意义也就不言自明了。

为什么写？

时下Spring Cloud Netflix全家桶已经成为了事实上的微服务实践落地的不二选择，笔者在公司也负责、参与一系列的微服务改造项目，该系列文章涵盖了笔者从刚接触该技术栈的入门到实战，再到源码分析的整个过程，是对自己经历的一次梳理，希望对您也有所帮助。

起因

经常看各类 javadoc 发现有一类 doc 并没有被做成标准的 doc 格式，直接复制出来想翻译一下，需要做一些预处理，比如删除注释、合并断行，前者各种编辑器的列模式搞定，后者就坑爹了，之前是手工一行一行的删除换行符，然后加空格的，非常坑爹。对于这类重复性操作，使用 vim 的宏录制就再好不过了。

></p>

背景

kafka 的诞生，是为了解决 linkedin 的数据管道问题，期初 linkedin 采用了 ActiveMQ 来进行数据交换，大约是在 2010 年前后，那时的 ActiveMQ 还远远无法满足 linkedin 对数据传递系统的要求，经常由于各种缺陷而导致消息阻塞或者服务无法正常访问，为了能够解决这个问题，linkedin 决定研发自己的消息传递系统，当时 linkedin 的首席架构师 jay kreps 便开始组织团队进行消息传递系统的研发；

提示: 本文是模型部署方案的一部分

依赖

• java8
• pmml-evaluator 1.4.2
• pmml-evaluator-extension 1.4.2

步骤

1. 使用JPMML执行引擎反序列化pmml文件
2. 模型校验（此处具体校验的问题，笔者以后另开一篇）

提示: 本文是模型部署方案的一部分

依赖

• java8
• pmml-model 1.4.2

步骤

1. 加载反序列化模型文件为PMML对象
2. 优化模型，并写到新模型文件

提示: 本文是模型部署方案的一部分

依赖

• spark 2.2
• jpmml-sparkml 1.3.8
• scala 2.11

步骤

1. 使用spark ml训练一个决策树模型
2. 在控制台验证可以输出后，写到文件中

提示: 本文是模型部署方案的一部分

依赖

• Python 2.7, 3.4 or newer.
• scikit-learn 0.16.0 or newer.
• sklearn-pandas 0.0.10 or newer.
• sklearn2pmml 0.14.0 or newer.

步骤

1. 使用sklearn训练一个模型
2. 使用sklearn原生API将模型导出为 pickle 格式
3. 使用 JPMML-SkLearn命令将原始pickle 格式文件转换成JPMML文件