从第一天当程序员开始，我觉得我的职业生涯也就两年三年，甚至在刚入行时第一年就觉得会是最后一年，可是五年六年，八年九年过去了，我从未想过自己可以走这么远。

在我最迷茫的时候，总能在网络上找到前辈们的有相同境遇，也总能找到问题的答案，使我不再那么烦恼。

生活已是不易，coder更加不易，最让我欣慰的是，这个行业总是不乏本领高强又愿意分享经验的前辈们，让我有坚持下去的动力。

所以，现在我只想写一点东西，哪怕职业生涯真的终止，起码回过头来还能看看当时的想法和境界。

 

微服务风

近年来服务器端技术又刮起了一股微服务风，“微服务”这个名词，就好像是横空出世，在2014年之前的书籍、考试用书、教材中，是我博览群书都前所未见的，请原谅我的才疏学浅。

因为种种原因，公司在某个项目中强制要求使用dubbo这个微服务，于是我也成为了这个城市中微服务大军中一员，带领小组突破微服务技术难题。

 

 

我们进步了吗

一年之间，一个接一个的项目后，玩转了微服务架构，注册发现、熔断、网关、消息、持续集成、容器，然后又退回来不用他们。

“空”，到头一场空。就好像做了一场梦一样，仿佛我们从来就没接触过微服务。

我试图回顾一下，这一年来我们进步了哪些，收获了什么，想想也不是原地踏步。

1、spring boot。由于spring cloud 强制要求使用spring boot，我们用上了这个，多个项目用下来，而且发现很好用，各种需求的考验下都没有让我们失望。

2、feign。feign client面向接口的调用，他简化了restful api的调用，自己写的http请求工具类也许可以退休了。

3、TDD、DDD。在某大神的指点下，面向接口的编程，遵循里氏替换原则。现在我们只要提供服务接口的定义，就能并行开发，然后做单元测试，而不需要等服务提供者开发完消费者端才能测试。开发难度提升就是多点几下ide自带的重构工具和编写单元测试用例，以前我们也很讨厌代码写这么规范，但比起微服务架构的开发管理成本和运维成本，多按那么几下alt+enter和shift+F6简直不算什么。

 

对公司的意义

对研发部门的影响意义最深远的，并不是开发语言，也不是技术选型，而是朴实无华的代码。

对公司开发管理层来说，技术框架选型最好是统一的，可以方便管理，人员替换。

但实际情况是不太可能的统一的，因为不可能是一成不变的，最终还是要尝试新框架的。

比如原来用angularjs，开始尝试vue.js，未来还有什么我们谁也说不准，

而且公司总有那么几个遗留项目，统一框架也只是一个理想状态吧，公司要发展，那是不可能不变的。

我们从研究dubbo和rocketmq就能看出，阿里内部肯定是把所有的mq玩个遍了，当年oracle替换mysql集群也只是一部分一部分的来。

包括京东的去.net化。

 

架构演化

除非是初创型公司，能够在创业阶段生存下来的公司，公司的生命周期总是大于技术框架或架构的生命周期。

最终，我们还是需要好的架构风格（指代码）去支持演化。

在这个技术框架快速变化的环境下，去寻找一些不变的真理。

 

不管开发语言如何变，公司业务不变。

不管技术框架怎么变，业务逻辑代码不变。

抓住了业务这个不变的点，围绕它来做文章。

 

解决方案

分布式系统的物理层次结构：

B/S三层：浏览器、服务层、数据库；业务逻辑在服务层

C/S两层：桌面应用胖客户端、数据库；业务逻辑在客户端

C/S三层：桌面应用瘦客户端、服务层、数据库；业务逻辑在服务层

这一块在我们公司是达成共识的，没有争议的。

 

逻辑层次结构：

我们现在大多的思维是展示层->业务逻辑层->数据访问层，业务逻辑层是无法单独拿出来运行、测试、重用，都要带上数据访问层。

这种思维是以数据库为核心的。文档和设计上也是注重er图表结构，程序也是脱离数据库无法单元测试，程序开发必须等数据库设计完成后才能开始，沟通当中也是频繁提及表结构。

所以业务逻辑是随着数据库变化的，从代码理解需求时很大程度还是要看sql语句。

未来我们的业务逐渐向云平台方向发展，势必在数据访问层平行引入MQ，内存数据库，分布式数据库技术，提供数据的服务（一部分的服务某种程度来说也是数据访问，比如调第三方服务，那么服务里面的业务是第三方的业务，不是我们的业务，对我们的业务来说服务就是我们的数据访问层）。

从代码层面理解需求或者沟通需求会变得越来越困难。

 

我们何不改变一下？只要简单地改变。

展示层->业务逻辑层<-数据访问层

 

近几个项目中就强制使用这种代码风格，小组成员也都能够很好地贯彻，是一个良好开端。

既然业务是核心，那么把核心独立出来，让那些非核心就去变吧。