春哥大魔王

jdgue

# 我的微服务之路
故事开端
　　故事开始于一年半前，当时还在维护着公司的一套老项目，项目虽老，但是每天的pv，up都是过千万的。理论上算得上是一个大项目，对于技术能力有一定的挑战。
　　公司历史悠久，项目架构庞杂，说实话进入公司之后好像没有听到如何强制的执行一些开发及代码规范，比如插件啦，git指南啦，codestyle啦，codereview流程啦。大多数程序员每天的任务就是完成运营或者产品同学的需求，说实话经过多年的发展，有点挑战的产品需求，或者革新比较大的改版需求早就让前人做了，新来的产品或者运营同学基本没有多少的需求或者革新可以做了，巧妇难为无米之炊。而开发人员做的基本就是sql改写，html页面的上线，代码逻辑三层架构即可。
　　没有架构师定时去分享一些架构经验，也少有大型挑战的项目给到开发同学去攻克与成长，说实话对于技术同学的成长是有一定限制的，所以如果有机会去做一个新项目，尝试一些新技术，对于每个开发同学其实是一件开心的事情。
古老的技术栈
　　前面说了，公司经过十来年的发展，随着业务的稳定，技术栈也相对稳定了，反过来说，技术栈稳定了，也就代表着轻易不敢在项目上动刀子。
　　公司历史遗留的技术栈有过php，.net，到后来的开始转型java，从单一的三层架构，后来分割的soa。一套业务系统里面，往往有着不一样的架构思路与设计。
　　当我有机会去做一个新的项目的时候，还是使用spring mvc,mybatis坐着三层开发。有一天看到了微服务架构的文章，看的久了慢慢对微服务的各个模块角色，开发方式，设计思想有了一定的理解，手痒想试试，想既然大项目没机会动手动脚，我是不是可以自己尝试用微服务的架构方式去重构古老的系统呢？
微服务架构的梳理
　　首先接触到的概念是“服务化”，说道服务化，过去几年市面上常见的解决方案多是围绕着dubbo的rpc通信方案。
　　最近一年的微服务思想多是围绕springcloud的方案。
　　dubbo用过很多次了，多是作为服务治理框架，在几年前他的设计思想还是比较优秀的。但是经过这么多年的发展，这种服务治理框架的实现可以有多种方式了，我自己实现过基于spring框架的服务治理框架，服务发现用的是zookeeper，通信两种netty和hessian，有机会说说这个。
　　当时spring cloud炒的很火，既然跟spring 有关，相信会勾起每个java开发人员的好奇心。
　　经过对于spring cloud工具集的学习，慢慢知道了一个标准的微服务架构所应该包含的功能点，如：

• 服务网关，主要为了统一验证与授权，当然也可以做限流。
  
• 注册中心，为了服务发现。
  
• 负载均衡。
  
• 异常处理与转移，可做降级处理与异常处理。
  
• 等。
  

　　于是开始对老系统进行业务与服务抽离，在原有系统结构上我主要可以抽离出30多个服务，主要的有比如：

• 登录服务 / 注册服务；
  
• 授权解密；
  
• 评论 / 回复；
  
• Feed流；
  
• 粉丝；
  
• 积分 / 签到；
  
• 头像；
  
• 标签；
  

　　抽离服务之后开始编码，受够了spring mvc繁杂的xml配置，决定使用spring boot。
　　第一次使用spring boot时候感觉像当年写php 从thinkphp到codeigniter，像当年从.net webform到.net mvc2.0的感觉，爽。
　　于是：

• SpringBoot做代码容器；
  
• 服务注册与发现用的是eureka；
  
• 网关用的是zuul；
  
• 统一配置用的是spring cloud config；
  

　　自己尝试跑起来之后基本顺滑了。整体上对于微服务的架构有所实践与了解了。
　　但是前文说了，项目老了基本没啥重构空间了，会了微服务暂时用不上啊。
我的微服务架构
　　用过spring cloud一套解决方案基本可以作为内网项目之间的解决方案，但是如果直接面对外网，前文说的解决方案是否还有效呢？
　　相信很少有直接将zuul面向外网的吧，放心一点的网关还是nginx靠谱。
　　我现在的项目的主要方式是前后端分离方式，前端包括了html，移动端，pad等。后端主要提供restapi，这样场景比较适合微服务的架构方式。
　　于是我们目前迭代到了下面的方式：

• 网关使用kong，主要借助nginx强大负载能力和kong本身丰富的插件，和当年使用kibana一样爽。
  
• spring boot一如既往的写起代码爽。
  
• 注册发现用zookeeper，这个基本属于行业标配。
  
• 统一配置用disconf，不爽的一点每次修改配置都需要重新发包，准备考虑用springcloud config，或者自己开发。
  
• 日志监控，一如既往的elk。
  

　　现在版本迭代的任务，基本交给质量管理团队，基于mesos marathon 的docker基本交给了运维团队，k8s暂时还搞不明白。
　　对了，换了团队之后，身边有了大牛可以学习的对象，对于项目开发的理解，对于技术团队的搭建，对于工程师团队的培养，对于数据化运营产品及团队合作与加班这件事情都有了一些新的看法，以后交流。