网易的工程师文化和微服务演进
1、张老师，您好，很高兴能采访到您。能否为壹佰案例的读者介绍一下自己？
张小刚: 大家好，我是张小刚，来自网易杭州研究院云计算部门。自2010年入职以来，一直从事基础设施的研发工作。现在主要作为云计算的架构师，以及多个团队的负责人。
我在这边也算是老人了，见证了很多产品的微服务架构演进，这次很高兴可以在top100平台和大家分享相关经验。
2、众所周知，网易是中国领先的互联网技术公司，您认为工程师在创新方面应该承担什么样的作用？能否为我们简单的描述一下网易的工程师文化？
张小刚: 网易更注重的是通过创新来解决问题。同时，我们的职责和工作内容，也会倒逼我们使用创新的思维和方案去解决问题。很多优秀的工程师对技术有天生的敏感性，在日常工作中，经常会自发的提出一些好的想法和创意，会通过筛选机制，把好的想法和方案固化下来。
另一方面，我们也会主动进行一些技术调研和POC，把评估结果较好的留下来，纳入我们的技术框架中，最终形成对外输出的解决方案。在这个过程中，工程师不但是执行者，同时也会参与到技术规划中来。
总结来看，我认为工程师作为开发第一线，是很多实际创新的提出和执行者，是技术创新的重要源泉。但是要注意的是，创新可能会引入风险和问题。因此需要审核和验证，把好的创新保存下来。
网易杭州研究院的整个研发氛围还是比较自由的，比较强调对人的尊重，以及经历发挥每个人的主观能动性。其中我感受比较深的是以下几点：
微服务项目技术架构
•务实：
实质上就是评估投入的回报率，回报可能是短期的效果，也可能是长期的技术红利。这样做的好处就是避免把人力浪费在一些无谓的跟风上面。集中资源投入在真正有价值的方面。
•分享和合作：
这边有比较强的分享氛围，从小组内的定期分享，到部门内的培训，以及跨部门的技术交流。这边也有很多机制来保证大家分享的积极性，比如一些小的奖励，绩效加分等。
•包容和技术导向：
在发生分歧时，我们一般通过技术交流来达成共识，而不是简单粗暴的利用上下级关系来强制执行。我们相信真理是越辩越明的，也很乐意听到不同的声音。比如，在一些面向新人的技术培训时，经常会有新人针对架构师的一些设计提出疑问（虽然大部分情况质疑是错的哈）。实际上，解答问题，通过会议/讨论解决技术分歧是我们日常工作的一部分。
•DevOps，技术主导：
我们部门本身是非常技术导向的，因此会强调研发同学的主观能动性。另外，我们内部已经普遍推广了DevOps。
总体来看，作为一家互联网技术公司，网易有自己独特的文化氛围，我觉得对工程师是很有吸引力的。
3、作为一家打造多款互联网爆款的公司，可以为我们讲述一下网易技术架构演进和业务的关系吗？
张小刚: 我认为这两者应该是一个相互促进，螺旋上升的过程。一方面，作为基础部门，会通过技术预研的形式引入新技术，并形成解决方案提供给产品团队。推动产品进行一些技术改造。另一方面，业务部门用户的爆发性增长，也会给基础服务提出更高的要求，倒逼着我们进行技术升级。
一般来说，这两者一般不会在一个平衡状态，当业务相对稳定时，我们这边会更多时间，帮助业务部门来提前进行技术规划，和架构演进。而当某些业务爆炸性增长，碰到一些棘手问题时。技术这边也会抽人力帮助业务部门制定解决方案，并将一些好的结果反向输出到我们的解决方案中，在公司内整体推广。
整体上看，我们技术部门和业务部门的合作是很顺畅的。最近一次比较大的技术改造就是网
易考拉，我们作为核心支撑部门帮助网易考拉平稳度过了双十一大促。
4、微服务架构经过几年的发展，可以说是百花齐放，各领风骚。网易是从什么时候开始着手于微服务设计的呢？此外，设计原则把控能为我们举例说说吗？
张小刚: 网易的服务化开始还是比较早的，从最早网易博客的服务化拆分开始，大概有近10年的历史了。这实际上还是在我进入网易之前，从前辈的大佬那里听到了不少辉（xue）煌（lei）史，这块也是我这次分享的一个重点。关于微服务的一些基本评估方式（低内聚高耦合之类的）就不再提了。我这里直接提几个我这边常用的，看起来非常简单，但却十分有效的原则：
1）评估投入产出比（ROI）:
这个其实是一个非常基础，但却很容易被忽视的原则。作为商业公司，任何投入都需要有回报（回报本身可以是短期的，或者是非常长期的技术积累）我们做微服务设计也是一样，需要思考投入的成本是否可以得到足够的回报。这一点说起来简单，但却是技术人员最容易犯的问题。特别是看到一些业界追捧的技术热点，或者醉心于精确的设计时，就很容易忽略了成本的投入。另外，当进展不是特别顺利时，可以停下来想想是否还需要继续投入。一些时候，壮士断腕比深陷泥潭会更好。
2）没想清楚就别乱动：
对于一些设计方案，如果无法判断是否要执行，较好的做法是先搁置起来，去做更明确的事情。对于非常重要的事情，在推进中就会将问题暴露得更加明晰，而对于一些非核心内容，在后续检验中可能就会被证明是没有必要的。一般来说，不动的话不会更差，但乱动往往会更糟。如果你连设计方案都没想清楚，那几乎是不可能顺利实施的。这个原则说起来很简单，但遗憾的是，在面临实际困难时往往会做出
错误的选择。这些实际困难可能是进度压力，对新技术的憧憬，或者对业务的熟悉了解程度。
3）风险把控：
我们做任何技术升级和改造，实际上都会有潜在的风险。而很多同学往往只看到光明的那一面，而忽略了阳光下的阴影。我们对于微服务的推进有很谨慎的流程。一般是新业务和较为独立的功能先采用，老业务根据实际情况，一般会先从边缘业务推进，根据实际情况逐步推进。
5、作为架构师，相信不能只看到微服务外部的世界，而轻忽或完全忽略了微服务内部的世界。所以，对于微服务中服务的粒度问题您是如何考量的？
张小刚: 我觉得微服务中的粒度本身和代码量多少并没有直接关系（至少不是强相关）。最关键的，还是粒度把控，是否符合业务特点，是否满足实际业务和场景需求，即对业务本身是否有帮助。如果仅仅是为了拆分而拆分，反而会徒增业务的复杂性。
关于这个问题，执行时还是有一些简单的标准可以参考的：
1）设计时预留拆分的能力。项目开始时可以不拆，但是要保留能力。
2）根据需要推进。在有明确需要（如业务分离，单独热点，独立升级等）时再进行业务拆分。切忌为了拆分而拆分。
3）明确服务边界。当弄清楚服务边界的时候，往往服务拆分就已经完成了。反过来说，如果你连服务边界都划分不清，那最好还是不要乱动。
4）微服务划分需要符合实际组织架构，规避跨团队服务。这个如果有维护跨团队服务经验的人，就会知道其中的痛了。
6、网易的产品可以说是多种多样，从网易博客到网易云音乐、网易考拉，相信网易内部也早已形成了一整套完整的微服务技术栈，能否为我们简述一下贵公司的微服务技术栈么？
张小刚：这个和问题7有重合，在问题7按照举例形式给了。
7、微服务是一个系统工程，主要包含哪些维度？
张小刚：基于微服务架构来实施项目，由于服务实例的大幅度增加，如果还采用原有的支撑体系，会造成开发，测试，运维成本的大幅上升，在一些场景下甚至是无法进行（比如全链路排障）。
因此，面向微服务技术，就需要新的工具和基础设施来进行支持，而这些设施之间也是会相互关联的。以网易云的轻舟微服务平台为例，大概可以分为以下六个维度：