学海无涯，心存高远。
项目背景
这时我就职于“南京十匠科技有限公司”，也就是 Bite Investments 技术团队的前身。
也是因为一个契机，南京十匠被 Bite Investments 收购，进行全球另类投资平台的研发工作。全新的平台技术架构商定使用微服务进行开发，我着手于后台架构的搭建。
Bite Investments 简介
创始团队来自英国，也是英国 VCP 的子公司。在纽约、开曼、伦敦、北京、南京、上海、香港、新加坡、首尔、东京均设有办事处。目前已经登陆亚洲、欧洲、美国金融市场。
技术选型
在这之前我参与了“咪咕互娱”一级用户中心的项目开发工作，以下这段经历简称为“用户中心项目”。当时“用户中心项目”项目经历了从 dubbo 转为 spring cloud 的过程，并且使用的技术栈是 Netflix 体系。
于是在 Bite Investments 上便沿用了这一技术体系。
黑暗岁月
在“用户中心项目”中有一整个团队来完成整个架构转型工作，而 Bite Investments 项目上初期只有我一个人负责架构搭建。光把一个 demo 搞起来就不知道付出了多少心酸。从对某一块负责到面面聚到，不知道熬过了多少夜晚。很感谢这段经历对我的洗礼。
探坑之路
config 配置中心无法自动触发更新
虽然说配置可以通过 config 进行获取了，但每次修改业务配置都需要进行服务发布是一个很头疼的事情。加上我们使用的还是国外的服务器，中间也没有对他进行优化，所以每次发布都是一个很耗时的过程。
想要实现自动更新要进行很多配置，先集成 bus，然后在引入 rabbitMQ。终于实现了配置更新，调用 bus 通知接口进行服务配置更新。
最终将配置陪到 github，利用 github 来触发服务更新，达到无手动干预自动更新配置。
feign 对异常的再次包装
使用 feign 做服务间调用 feign 会将服务抛出的异常自动进行包装，导致异常没有办法进行获取。
实现 ErrorDecoder 接口，重写 decode 方法，对 response 进行再次处理。
feign 对 get 类型请求无法进行参数传递
实现 RequestInterceptor 接口，重写 apply 方法，重新处理 request 对象。
分布式事务
由于数据需要跨服务进行回滚，又因为使用了 mongo + mysql 两种持久化数据库，时间也比较紧迫，我们需要尽快进行业务开发。临时选用了 ByteTCC 进行事务处理。
事后证明这是一大败笔。笨重的业务嵌入导致无法进行敏捷开发，对使用要求也很高。
分布式日志
未做分布式日志以及调用链追踪，导致后期查错非常困难。
经验教训
-
在项目启动之初没有花更多的时间去进行技术选型，而是急于进入业务开发。然而导致了后期开发过程中的各种疑难杂症。
-
只是对微服务某一技术实现有所了解是不够的，需要全方位多技术实现有所认知才能摆脱管中窥豹的窘境。
收获
-
最微服务架构有了全面了解。
-
有了最初的微服务架构经验，在日后学习、工作中有更好的对照思考。