2018年总结

从第一天当程序员开始，我以为个人职业生涯也就两年三年，甚至在刚入行时第一年就以为会是最后一年，但是五年六年，八年九年过去了，我从未想过本身能够走这么远。

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

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

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

 

微服务风

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

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

 

 

咱们进步了吗

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

“空”，到头一场空。就好像作了一场梦同样，仿佛咱们历来就没接触过微服务。

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

一、spring boot。因为spring cloud 强制要求使用spring boot，咱们用上了这个，多个项目用下来，并且发现很好用，各类需求的考验下都没有让咱们失望。

二、feign。feign client面向接口的调用，他简化了restful api的调用，本身写的http请求工具类也许能够退休了。

三、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，内存数据库，分布式数据库技术，提供数据的服务（一部分的服务某种程度来讲也是数据访问，好比调第三方服务，那么服务里面的业务是第三方的业务，不是咱们的业务，对咱们的业务来讲服务就是咱们的数据访问层）。

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

 

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

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

 

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

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