张小刚，网易云基础服务架构师，负责网易云多Region、多AZ、VPC整体架构设计和推进工作，在负载均衡、分散式系统方面有丰富的经验。在本文中，张小刚为我们解答了微服务对于网易业务发展的意义，以及团队在微服务方面的实践经验与心得。本文由原载于公众号技术琐话，有改动。

Q：作为一家打造多款互联网爆款的公司，网易技术架构演进和业务的关系如何？

张小刚: 我认为这两者应该是一个相互促进，螺旋上升的过程。一方面，作为基础部门，我们会通过技术预研的形式引入新技术，并形成解决方案提供给产品团队。推动产品进行一些技术改造。另一方面，业务部门用户的爆发性增长，也会给基础服务提出更高的要求，倒逼著我们进行技术升级。

一般来说，这两者一般不会在一个平衡状态，当业务相对稳定时，我们这边会更多时间，帮助业务部门来提前进行技术规划，和架构演进。而当某些业务爆炸性增长，碰到一些棘手问题时。技术这边也会抽人力帮助业务部门制定解决方案，并将一些好的结果反向输出到我们的解决方案中，在公司内整体推广。

整体上看，我们技术部门和业务部门的合作是很顺畅的。最近一次比较大的技术改造就是网易考拉，我们作为核心支撑部门帮助网易考拉平稳度过了双十一大促。

Q：微服务架构经过几年的发展，可以说是百花齐放，各领风骚。网易是从什么时候开始著手于微服务设计的呢？此外，设计原则把控能为我们举例说说吗？

张小刚: 网易的服务化开始还是比较早的，从最早网易博客的服务化拆分开始，大概有近10年的历史了。这实际上还是在我进入网易之前，从前辈的大佬那里听到了不少辉（xue）煌（lei）史，这块也是我这次分享的一个重点。关于微服务的一些基本评估方式（低内聚高耦合之类的）就不再提了。我这里直接提几个我这边常用的，看起来非常简单，但却十分有效的原则：

1）评估投入产出比（ROI）:这个其实是一个非常基础，但却很容易被忽视的原则。作为商业公司，任何投入都需要有回报（回报本身可以是短期的，或者是非常长期的技术积累）我们做微服务设计也是一样，需要思考投入的成本是否可以得到足够的回报。这一点说起来简单，但却是技术人员最容易犯的问题。特别是看到一些业界追捧的技术热点，或者醉心于精确的设计时，就很容易忽略了成本的投入。另外，当进展不是特别顺利时，可以停下来想想是否还需要继续投入。一些时候，壮士断腕比深陷泥潭会更好。2）没想清楚就别乱动：对于一些设计方案，如果无法判断是否要执行，较好的做法是先搁置起来，去做更明确的事情。对于非常重要的事情，在推进中就会将问题暴露得更加明晰，而对于一些非核心内容，在后续检验中可能就会被证明是没有必要的。一般来说，不动的话不会更差，但乱动往往会更糟。如果你连设计方案都没想清楚，那几乎是不可能顺利实施的。这个原则说起来很简单，但遗憾的是，在面临实际困难时往往会做出错误的选择。这些实际困难可能是进度压力，对新技术的憧憬，或者对业务的熟悉了解程度。3）风险把控：我们做任何技术升级和改造，实际上都会有潜在的风险。而很多同学往往只看到光明的那一面，而忽略了阳光下的阴影。我们对于微服务的推进有很谨慎的流程。一般是新业务和较为独立的功能先采用，老业务根据实际情况，一般会先从边缘业务推进，根据实际情况逐步推进。

Q：作为架构师，相信不能只看到微服务外部的世界,而轻忽或完全忽略了微服务内部的世界。所以，对于微服务中服务的粒度问题您是如何考量的？

张小刚: 我觉得微服务中的粒度本身和代码量多少并没有直接关系（至少不是强相关）。最关键的，还是粒度把控，是否符合业务特点，是否满足实际业务和场景需求，即对业务本身是否有帮助。如果仅仅是为了拆分而拆分，反而会徒增业务的复杂性。

关于这个问题，执行时还是有一些简单的标准可以参考的：1）设计时预留拆分的能力。项目开始时可以不拆，但是要保留能力。2）根据需要推进。在有明确需要（如业务分离，单独热点，独立升级等）时再进行业务拆分。切忌为了拆分而拆分。3）明确服务边界。当弄清楚服务边界的时候，往往服务拆分就已经完成了。反过来说，如果你连服务边界都划分不清，那最好还是不要乱动。4）微服务划分需要符合实际组织架构，规避跨团队服务。这个如果有维护跨团队服务经验的人，就会知道其中的痛了。

Q：微服务是一个系统工程，主要包含哪些维度？

张小刚:基于微服务架构来实施项目，由于服务实例的大幅度增加，如果还采用原有的支撑体系，会造成开发，测试，运维成本的大幅上升，在一些场景下甚至是无法进行（比如全链路排障）。

因此，面向微服务技术，就需要新的工具和基础设施来进行支持，而这些设施之间也是会相互关联的。以网易云的轻舟微服务平台为例，大概可以分为以下六个维度：

1）微服务框架：这个是实现微服务的基础设施，比如服务注册/发现，服务拓扑，配置管理等。在轻舟微服务平台中，我们自研了一套微服务框架NSF，完全兼容Spring Cloud和Dubbo，不但提供了服务注册/发现，列表，路由等基础功能，还提供了服务容错，服务降级，限流等高级特性。

2）RPC通道/API 网关：做了细粒度的拆分后，作为服务边界的API的统一治理就特别重要。API网关实现服务鉴权，流控/熔断，发布管理等功能。在轻舟微服务平台中，我们是使用自研的API网关来实现的。除了API网关的基本特性（鉴权，流控）之外，还和整个服务体系打通，提供了审计，多维度故障隔离，流量控制等能力。3）底层设施：底层设施的支持也必不可少，这方面云计算有天生的优势，特别是容器服务。网易云轻舟微服务基于Kubernetes实现，支持容器编排，弹性伸缩，镜像管理等。4）面向微服务的运维工具：微服务架构带来巨大的变化，原有工具很难满足要求，需要面向微服务设计，更为智能的运维工具。轻舟微服务直接提供了统一的控制台，所有功能都可以直接在界面操作。并且集成了自研的全链路监控工具，可以快速定位问题。这边现在重点在推进智能运维，包括异常智能检测，关联报警分析，故障根因分析等。5）DevOps：这块主要包括从开发到构建的流程管理，提供代码仓库，构建发布管理，pipeline管理等。轻舟微服务平台整合Kubernetes，支持完整的DevOps流水线，可以直接构建完整的CI/CD服务。 6）自动化测试：包括故障演练，性能压测，API测试，异常定位/回滚等。轻舟微服务集成了网易自研的自动化测试平台，对应平台在网易内部经过了长期的应用，并广泛应用在网易内部重大产品的测试中。

Q：网易在在引入微服务的过程中，有没有发生过一些有意思的故事？

张小刚: 网易引入微服务的过程，就是一个不断踩坑->填坑螺旋上升的过程。我们也正是因为碰到并解决了那么多的问题，才最终形成一个较为完整的微服务技术栈。这里有一个比较有趣的例子：

当微服务概念刚刚兴起的时候，我们的一个技术团队决定开始实施微服务。他们当时维护的是一个单体架构，做了不错的模块划分，但是并没有实现服务化。他们微服务的第一步就是服务拆分，而且拆的很细。细到什么程度呢？最终从一个由几个模块构成的单体服务，拆到了四五十个服务的样子。

其实他们的设计能力和拆分并没有太大问题，粒度模块划分，边界定的也算清楚。但是，在拆之后还是面临了很大的困难。最大的问题就是当时我们的运维部署工具没有跟上，还是沿用老的一套，需要人为控制服务发布。而他们的需求很多，一次大的功能需求往往需要十几个，甚至几十个服务共同升级，而服务相互之间还有一些前后升级的依赖关系。结果，最先做了微服务的团队，变成每次升级最为困难，升级成本最高的团队。经常是其他服务已经升级部署好了，他们还在那边一个个的进行服务发布。现在还能记得他们苦逼的眼神。但这个团队还是很有办法的，干脆直接引入了一套底层Kubernetes，完全接管了运维。后续又逐步引入各种微服务工具，才逐步体会到了微服务的优势。实际上，这个团队后来成为了轻舟微服务团队的主力，而当时他们踩过的坑都变成了我们的宝贵经验。

Q：目前贵公司微服务的实施状况是怎样的，下一步要解决哪些问题？

张小刚: 网易内部现在大部分互联网服务都在不同程度的进行了微服务化实践，并且已经在线上运行了。

我们云计算部门也形成了一套完整的微服务解决方案，并封装成为一个独立的产品----轻舟微服务平台，现在已经成功对外输出微服务能力，应用于金融、物流、制造等领域。

下一步的目标，主要还是完善功能，比如：ServiceMesh的支持，让服务发现对应用完全透明；提供对分散式事务的支持，简化分散式事务的开发和使用。其他还有很多具体的功能点，这里就不细说了。

推荐阅读：

相关文章