最近这几个月文章更新处于停滞状态，因为公司的事情比较多，公司系统一直处于高速的迭代更新阶段，
尽管如此，我这段时间也一直在整理接下来要更新的文章大纲以及知识点的梳理，希望在后续的文章更新中能给这段时间关注我的朋友以及将要关注我的朋友帮助。
程序员应该保持一颗好奇心
程序员应该保持一颗好奇心这句话我经常告诫我部门的员工，无论在什么情况下你都应该一颗好奇的心，敢于去追寻，敢于去创新，技术行业是一个以新型技术驱动的行业。
初识分布式解决方案
公司系统在最早是一套原始的SSM框架搭建的整体架构，这种方式的弊端相信大家也都有很多的了解，从SSM到SpringBoot项目的整合然后再到SpringCloud分布式部署是一个很漫长的过程，系统内部有很多原始的业务在里面，有很多比较繁琐以及冗余的代码在里面，正因如此，我们才开展了代码的重构。
由于我一直在编写SpringBoot方面的文章，所以无疑采用了SpringCloud作为分布式部署的解决方案，在这个过程中是比较艰辛的，要考虑的地方比较多，原始业务的正常运营，新业务的扩展以及部署。
虽然会遇到各种各样的问题，还是毅然的选择了这条道路，因为系统要在不断的升级维护、重构过程中才能更不断的完善。
原业务请求转发
由于时间问题，原始的业务不能快速的全部采用分布式编码方式进行重新编写，通过SpringCloud的gateway统一网关来进行转原业务的请求分流，在做路径路由设置时要注意转发的前缀，因为我们原接口都是以版本号进行前缀访问的，所以比较容易根据指定的版本号进行过滤，如：/v2/**，然后配置url进行转发到原nginx入口。
原始业务的服务拆分
那么接下来的一步就是对原始业务的拆分，对于微服务(microservice)的拆分，一般都是采用具体的业务原子性，比如：我提供一个用户服务，这样其他的服务通过feign可以直接调用该服务内的方法并获取相应的数据。
通过这种原子性的服务拆分规则，我们就可以罗列出原始业务能够拆分成的服务列表，当然建议把每一个服务对应的端口号范围进行提前约定，这样在编写的过程中也不会出现端口号的占用。
可以参考下面的表格进行记录：
| 服务名称 | 服务描述 | 服务端口号 |
|---|---|---|
| api-service-user | 用户微服务 | 10000~10004 |
| api-service-good | 商品微服务 | 10005~10009 |
整合部署
通过前期的技术选型到实现方案再到集成部署都是一个比较敏感的阶段，如果你的团队刚开始使用SpringCloud中间肯定会有很多需要磨合的地方，不过对于团队的开发其实影响也不是特别大，开发人员只不过是需要了解：
- 服务之间的调用
- 服务注册
- 服务调用
部署人员把相关的服务注册中心、统一网关、统一认证中心等搭建完成后，服务也就是简单的配置下对应的就可以实现对应的功能！！！
写在最后
微服务是目前比较流行的一种搭建部署解决方案，不过不要盲目的更换公司的部署方案以及编码框架，前期要做好详细的调研，把可能会遇到的问题进行汇总并找出相应的解决方案，这样才不会在重构过程中走的比较困难，甚至寸步难行！！！
