前言
一直在前端耕耘，发现目前Pure FE实现的microservices总有各种不妥，于是乎尝试接触回一开始的Java系
阅读之前可以看看这篇文章了解Spring Cloud ：中小型互联网公司对于Spring Cloud的选择与思考
纯吐槽，可以无视这段文字。这里很想解释为什么这里要说“接触回Java”，当年其实也是Java出身，但是各种痛苦啊，下个jdk配置环境变量，好不容易好了下个eclipse，结果官网下载还要翻墙，当年渣渣不懂搭梯子啊，真的是泪崩，好不容易搞好eclipse了，结果Eclipse里面Build Path不对又是一通乱搞，好不容易都妥当了，jdbc连个数据库又是各种安装，我想要个SQL数据库而已，不懂装，结果装了占用贼大的空间，当年那个电脑真的是“纯办公”电脑，经不起这些折腾，终于完整做完那个学期的期末项目后....
回到正题，接触microservices其实当初有两个选择：
- Dubbo
- Spring Cloud
都用过才知道优劣，于是两个都让它成功跑起来了
其实首先了解到的是Dubbo，毕竟挂了“阿里”的名号
但是发现Dubbo admin的UI像是上个世纪的产物,然后integrate了zookeeper后就另玩玩Spring Cloud
Dubbo UI 了解一下
后来继续了解microservices，结果发现还有个庞然大物叫Spring Cloud，于是抱着了解的态度搜索了一些资料。
结果发现需要了解的东西异常多，有点像要玩React的时候，发现要玩的还有Webpack，Redux, Router v4，Saga...等等N系列的包一样的感觉
也好在有这种经历，看到这么多sets倒也不会太胆怯，于是乎各种尝试跑了跑，结果有惊喜。
以往玩的时候没有maven，用得是eclipse，现在玩，基于spring boot， 用IDEA，结果真的是一路畅通（哈哈会不会也有当初搞环境的功劳）
于是搭起来了一份包含了：
对于Spring Cloud:
- Eureka 注册中心
- Ribbon实现REST Load balance
- REST热部署
- Fegion声明式调用
- Hystrix服务熔断降级方式
- Zuul实现微服务网关
- Config Server实现分布式统一配置
- Bus + Sleuth实现service链路追踪
对Spring boot service：
- Swagger UI做API Doc，这个贼赞
- Actuator进行单个服务的具体信息查找，如性能什么的，具体还得有项目玩才知道
hm应该没其他了，有再接触接触
其实就单个service来说也有相当多的东西可以写，比如swagger UI， Actuator等
但是这次让我贼感兴趣的是"Full Picture"，在网上找了个教程学习搭建下
整个Spring Cloud家族，成功搭建起来，发现确实，后端的世界比我之前接触的先进很多很多了
Demo全图
- 基于Docker + mongoDB (不好意思，对这个数据库比较熟，而且做demo可以很快)在本地起个Portable的数据库
- 创建Spring config server, 实现服务创建的配置集中化
- 基于Spring boot + mongoDB实现 CURD,以 Customer为例子，算是初步了解spring boot的service搭建吧
- 基于Spring boot + mongoDB，创建一个提供Rate的服务，读取MongoDB里面的数据
- 基于Spring boot，创建一个Rate转换服务，实现服务调用者的调用逻辑
- 用Zuul创建API Gateway，让所有服务通过API Gateway调用
- 用Eureka创建一个注册中心，让所有的服务集中管理，查看已启动的所有服务
- 通过Zipkin, Sleuth实现服务调用的链路追踪
Phase 1 创建配置中心 + 创建Customer CURD
-
MongoDB
MongoDB - Customer -
Spring Config server + Customer Service
Spring Config server + Customer Service
本来这些配置在项目之下，现在提权到config server所对应的配置中心处，并且可以设定是Dev还是UAT环境使用相应的配置
其实这一步挺麻烦，不过搞清楚如何在Docker下使用mongoDB和设置相对应DB里Document的权限配置就可以了
效果：
剩下的都不放图了，差不多的
Phase 2 创建exchange-rate-provide-service，读取MongoDB数据
-
MongoDB
Dum了Rate data - exchange-rate-provide-service
这里得强调下，在8000端口启动这个服务
Phase 3 创建rate-convert-service, 调用exchange-rate-provide-service
就是汇率转换的服务，调用调取数据库的汇率服务
进到程序启动的log里面查看：
同时有log刷新，成功调用，这里的port是指调取数据库汇率服务的服务提供接口，在这里输出8000以此为Load Balance，负载均衡做鉴别
Phase 3 创建Zuul API Gateway做服务接入口
在8765端口创建及启动Zuul API Gateway,
然后在Service端设置相对应的Proxy即可
这时候通过API Gateway call之前创建的这两个服务
API Gateway call的规则是：
http:
ex.
http://localhost:8765/exchange-rate-provide-service/exchange/from/USD/to/CNY
不过这里直接Call调用Rate的convert service吧，更直观
然后看看API Gateway + convert + rate 三个APP的log
API Gateway：可以看到
一个Triggle，起了两个Request，即其实服务流向是：
API Gateway => Convert Service => API Gateway => Rate Service
这里还用到了Sleuth做某个API call的链路追溯，黄色hightlight处第一个参数，就是Sleuth自动gen的，给这一个API call的id: 6c0e74a63dd6c9b4
Phase 4 创建Eureka server，注册所有service
目前看到的所有都不是UI层面的，开启的服务有多少，并不能清楚(一两个可以，多起来上百个的话，记不清的)，所以必须有个服务注册中心，Eureka就充当这个角色
简单创建，启动在端口8761，再根据文档注册所有service,包括API Gateway
可以看到已经起来的API service instance
当然会显示一些常用的Info
Phase 5 Load Balance，负载均衡检测
接下来检测下load balance的功能是否还在
在8001端口启动rate service，这里假设的是读取数据库/调用rate需要更大的消耗，需要更多service来提供服务，在另一个端口启动可以模拟在另一个服务器起这个instance
成功启动后，刷新Eureka UI，你会发现：
Eureka自动发现相关的service并注册进去，其实API Gateway也是，只能从log查看
全程不需要重启任何服务，现在重新Call convert service
实际这里这个Port作为一个鉴别作用，如果不输出，Consumer是完全不知道区别的
Phase 6 Zipkin 信息链路追踪
根据官方文档，安装Erlang, Rabbit MQ启动Zipkin，配置已有服务，启动Zipkin：
然后选择服务名查看即可：
可以查看整个Call的链路，以及耗时，对我这个乡里人来说，感觉还是很惊艳的
后话
至此，整个Demo基本就结束了。
还有很多功能，比如HATEOAS，Hystrix服务熔断，SwaggerUI，Actuator，JSON to SOAP自动转换，多语言，版本迭代等实现是实现了，但比较细，点比较多，而且应该属于Spring boot service单个使用比较合适，抽空整理再另外写个Demo，再写写
Keep Moving
搞点这些，前后端的seed有了，可以写个小demo项目玩玩
附：
前端Seeds: AoneFlow代码管理实践 + React + Redux + StyledComp + Intl 实现应用多语言多样式开发
后端Seeds: Spring boot service全家桶实现（未发布）