前言
工作这些年，先后经历过两家公司，有参与过php语言框架的开发和主导过go语言技术栈的落地工作，在此过程中有一些感悟和总结。我想以之前我主导的go语言技术栈为线索，来陈述当时遇到的一些问题，以及分析问题和解决问题的思路。主要目的是想陈述go技术体系在团队中落地的过程，分析我们在各个阶段中，遇到的一些问题，并将分析问题的思路和解决问题的方法记录下来，以便让后来的同学了解go语言在团队的演进过程，吸取相关的经验，以便在今后的系统设计和开发上少走弯路。
在系统不断演进的过程中，有时候对框架的选型很随意，认为能满足现在功能就行，没有对其功能扩展性和性能进行考量，导致随着业务的发展，发现当时选型有误，但想转又很难。那么现在，我就来谈谈，我们是如何抉择这些事情的。
我们为什么要由php转向go最初，大约是在年时，平台内所有的业务系统均是由php语言构成的，上线没多久，平台的流量开始爆发性增长，并发量越来越大，晚高峰每秒请求由最初的几千QPS到现在的几十万QPS。当时，最快最有效的优化手段无外乎加机器和增加php－fpm的数量，但是，受限于php本身的网络模型，终究不适合这种高并发，大流量的场景。面对这种棘手的问题，再加上当时人手有限，业务任务重等因素，于是找其它部门借了一批写lua的外援，帮忙把一些逻辑简单且访问量大的接口，换成了lua，暂时扛过了晚高峰，因此，有相当长的一段时间，大部分项目是php＋lua共存的一个状态。但由于lua本身的一些局限性，不太适合做一些复杂的业务逻辑，所以最终，在业务有强烈的需求的前提下，同时伴随着技术发展的潮流，于年底，我们开始选择转向go语言。
我们怎样由php转向go由于之前团队全部都是php栈，在go方面的积累并不多，所以在php转向go的过程中，面临了在转型过程中都会遇到的问题：
1用什么框架；
2在业务任务重，人员极其匮乏的情况下如何將php项目重构成go。
用什么框架之前团队有人仿造内部php框架开发过一个golang框架，有人提议将其直接拿过来用，有人说找个开源的如beego，gin，martini等这类流行的框架。我个人当时不太赞同使用自研的框架，主要有以下几点原因：1文档少，漏洞多；2需要投入人力去开发和维护，在当时人力极其紧缺的情况下是不现实的。另外，当时社区流行的框架也比较多，但是最终也没有选择那些流行的框架，主要是出于以下考虑：时间短，任务重，没有精力去辨别各个框架的优劣，适用场景以及性能如何。万一冒然使用一个还没有深入了解的框架，线上出问题咋办！尤其在当时系统频繁出问题，顶着各种压力的情况下。
虽说，我们无法在短时间内选一个合适的框架，但是能够确定的是：我们的需求是什么？
1只做高性能的HTTP接口；
2需要完整的单元测试体系；
3可扩展，组件化；
基于以上三点，可以发现，go语言自带的特性就可以满足这些需求。于是，我们开始决定裸写。
此外，还有一个裸写的原因就是：没想好将来想要什么！当然，每个团队的背景不一样，业务场景也不同，在人力和时间充裕的情况下，还是需要选择一个合适的框架比较好。
裸写不是乱写裸写不是乱写。众所周知，用框架的其中一个好处就是保证团队代码风格的一致性，当然，目前市面上除了beego外的大多数框架，在代码风格上也并没有做约束。为了保证团队go代码的规范性和一致性，按照经典的分层架构和过往的经验，我们制定了一套go编程模版，由上向下：Router层，Service层，Dao层，还有贯穿这三层的Entity层，架构图如图1所示。其中，Router层负责处理与