个人微服务之路

# 个人微服务之路

故事开端

故事开始于一年半前，当时还在维护着公司的一套老项目，项目虽老，可是天天的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暂时还搞不明白。

对了，换了团队以后，身边有了大牛能够学习的对象，对于项目开发的理解，对于技术团队的搭建，对于工程师团队的培养，对于数据化运营产品及团队合做与加班这件事情都有了一些新的见解，之后交流。