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、微服务是一个系统工程，主要包含哪些维度？
张小刚:基于微服务架构来实施项目，由于服务实例的大幅度增加，如果还采用原有的支撑体系，会造成开发，测试，运维成本的大幅上升，在一些场景下甚至是无法进行（比如全链路排障）。
因此，面向微服务技术，就需要新的工具和基础设施来进行支持，而这些设施之间也是会相互关联的。以网易云的轻舟微服务平台为例，大概可以分为以下六个维度：
1）微服务框架：这个是实现微服务的基础设施，比如服务注册/发现，服务拓扑，配置管理等。在轻舟微服务平台中，我们自研了一套微服务框架NSF，完全兼容Spring Cloud和Dubbo，不但提供了服务注册/发现，列表，路由等基础功能，还提供了服务容错，服务降级，限流等高级特性。
2）RPC通道/API 网关：做了细粒度的拆分后，作为服务边界的API的统一治理就特别重要。API网关实现服务鉴权，流控/熔断，发布管理等功能。在轻舟微服务平台中，我们是使用自研的API网关来实现的。除了API网关的基本特性（鉴权，流控）之外，还和整个服务体系打通，提供了审计，多维度故障隔离，流量控制等能力。
3）底层设施：底层设施的支持也必不可少，这方面云计算有天生的优势，特别是容器服务。网易云轻舟微服务基于Kubernetes实现，支持容器编排，弹性伸缩，镜像管理等。
4）面向微服务的运维工具：微服务架构带来巨大的变化，原有工具很难满足要求，需要面向微服务设计，更为智能的运维工具。轻舟微服务直接提供了统一的控制台，所有功能都可以直接在界面操作。并且集成了自研的全链路监控工具，可以快速定位问题。这边现在重点在推进智能运维，包括异常智能检测，关联报警分析，故障根因分析等。
5）DevOps：这块主要包括从开发到构建的流程管理，提供代码仓库，构建发布管理，pipeline管理等。轻舟微服务平台整合Kubernetes，支持完整的DevOps流水线，可以直接构建完整的CI/CD服务。
6）自动化测试：包括故障演练，性能压测，API测试，异常定位/回滚等。
轻舟微服务集成了网易自研的自动化测试平台，对应平台在网易内部经过了长期的应用，并广泛应用在网易内部重大产品的测试中。
8、网易在在引入微服务的过程中，踩过哪些坑？有没有发生过一些有意思的故事？
张小刚: 网易引入微服务的过程，就是一个不断踩坑->填坑螺旋上升的过程。我们也正是因为碰到并解决了那么多的问题，才最终形成一个较为完整的微服务技术栈。踩坑的主要内容我在分享中都会提到，这里举一个分享中没有，但比较有趣的例子：
当微服务概念刚刚兴起的时候，我们的一个技术团队决定开始实施微服务。他们当时维护的是一个单体架构，做了不错的模块划分，但是并没有实现服务化。他们微服务的第一步就是服务拆分，而且拆的很细。细到什么程度呢？最终从一个由几个模块构成的单体服务，拆到了四五十个服务的样子。
其实他们的设计能力和拆分并没有太大问题，粒度模块划分，边界定的也算清楚。但是，在拆之后还是面临了很大的困难。最大的问题就是当时我们的运维部署工具没有跟上，还是沿用老的一套，需要人为控制服务发布。而他们的需求很多，一次大的功能需求往往需要十几个，甚至几十个服务共同升级，而服务相互之间还有一些前后升级的依赖关系。
结果，最先做了微服务的团队，变成每次升级最为困难，升级成本最高的团队。经常是其他服务已经升级部署好了，他们还在那边一个个的进行服务发布。现在还能记得他们苦逼的眼神。
但这个团队还是很有办法的，干脆直接引入了一套底层Kubernetes，完全接管了运维。后续又逐步引入各种微服务工具，才逐步体会到了微服务的优势。实际上，这个团队后来成为了轻舟微服务团队的主力，而当时他们踩过的坑都变成了我们的宝贵经验。
9、目前贵公司微服务的实施状况是怎样的，下一步要解决哪些问题？
张小刚: 网易内部现在大部分互联网服务都在不同程度的进行了微服务化实践，并且已经在线上运行了。
我们云计算部门也形成了一套完整的微服务解决方案，并封装成为一个独立的产品----轻舟微服务平台，现在已经成功对外输出微服务能力，应用于金融、物流、制造等领域。
下一步的目标，主要还是完善功能，比如：ServiceMesh的支持，让服务发现对应用完全透明；提供对分布式事务的支持，简化分布式事务的开发和使用。其他还有很多具体的功能点，这里就不细说了。
10、11月30日-12月3日，由msup主办的第七届TOP100全球软件案例研究峰会将在北京国家会议中心举办，作为本届架构专场的讲师，可以说一下您分享的话题《完整微服务技术栈的定义和实践探索》，能否剧透一下，这次您给大家带来了什么样的干货？
张小刚:这次分享的内容主要是对网易近10年服务化历程的一个总结，并从中挑选出一些比较有代表性的例子和大家分享。可能是经历了太多的血泪了，我这边会特别强调风险控制，因此我的分享也会偏向遇到的问题（当然会有解决方案）。毕竟有那么多同学在推广微服务了，有人像我这样提示下风险，对微服务项目的成功很有现实意义。