罗毅，花名北纬。这个名字，如果是混过天涯论坛的大龄网民应该都不陌生，北纬67度3分周公子（简称北纬）虐杀易烨卿MM的世纪大战至今还是天涯神贴 ，当时更是有看客赋诗形容：“目睹此帖，开怀大笑，行走论坛，此帖独尊。”可见其影响力。

罗毅取花名为北纬，可以说是怀念这段经典，致敬周公子。

孔子说，40而不惑。如今的罗毅应该就是这个状态了，对人情世故有所清明，对自己的状态，尤其是所做的工作有着清楚的认知，对未来也有一定的计划。

20余年的从业履历，不能说每一段都足够完美，但无论是在Oracle（世界百强，全球最大的企业级软件公司），还是在BEA 系统（著名的Java 中间件软件公司），抑或如今的阿里，都在北纬的人生履历上留下了足够漂亮的一笔。

谈“阿里”

在阿里工作是一种什么体验？阿里的江湖里有武侠情结

北纬是在2014年7月份进入阿里的，就在将近2个月内，阿里在纽约证券交易所正式挂牌上市。他算是见证了阿里成长的老员工，目前主要负责中间件小组工作、微服务、RPC框架等内容。

程序员心向往之的大厂阿里究竟是什么样子呢？北纬给出了自己的一些看法。

• 阿里有哪些特殊的企业文化？

我认为阿里最出名的企业文化就是武侠文化了，表现在每个人都有花名。最开始的花名都是来自金庸小说（譬如风清扬、郭靖、杨过等），还挺好记的，后面人多了，会发现要记住所有人的花名开始变成不容易。

此外 ，比如用内网登陆阿里的单身GO，可以让单身男女青年内部消化，打开钉钉内部群，可以联系到阿里系所有的人，包括马老师。都是阿里很有意思的一些东西。

• 面试阿里，哪些会是候选人的加分项？

我们最关注的是候选人个人追求的核心价值，和团队正在做的事情以及未来方向是否高度契合。而在个人素质方面，主要关注聪明、坦诚、有热情这3个方面。

• 由于体量大，阿里的业务之间会不会存在比较多的交叉，对技术人员也有不同业务线协作的需求？

根据康威定律，组织架构决定软件架构。

阿里是国内最早做服务化改造的公司，架构按照服务拆分，不同业务之间的交互主要是通过契约，契约不变的前提下各团队各司其职。业务线之间的协作往往也会发生，典型的会发生在影响上下游的新版本发布或者横向的架构改造升级。因此，这类事情对于中间件团队等基础架构部门比较多一点。

• 同一发展阶段，技术人在阿里的最大的收获会是什么？

我认为技术人在阿里工作，面对的主要是双十一的体量对软件、架构设计上的挑战，能够更真切地感受到自己负责的组件在其中承担的作用从而带来了很大的成就感。

谈“Dubbo”

时隔3年 阿里的开源Dubbo 3.0满血复活！

对于 Dubbo 框架，大部分 Java 开发者都不会感到陌生，它自诞生起就备受关注。

2012 年，阿里巴巴在 GitHub 上开源Dubbo，许多开发者及公司都青睐于使用Dubbo来解决服务化问题。去年11月份，阿里宣布重启Dubbo开源，那么目前Dubbo的开源进展如何？

北纬就是Dubbo开源项目和内部服务框架的负责人，场主和他也聊到一些大家所关心的关于Dubbo的问题：

• 你是什么时候接手Dubbo项目，在此之前对Dubbo的了解程度如何？

我正式接手Dubbo是从2017年7月份开始的，以前其实也陆陆续续维护过 Dubbo，比如 2016 年里也做过相关尝试。

我对 Dubbo 的了解主要来自梁飞在 JavaEye 的系列文章，再通过自己阅读源码，以及在内部 RPC 框架对 Dubbo 兼容的工作中学习所得。而在正式接受Dubbo项目后，我又开始认真地体系地去了解 Dubbo 。

出于统一运维的考虑，阿里内部使用的是一个比开源版本更先进的服务框架，这个框架经历了历年双十一大促峰值的考验。

目前 Dubbo 开源和内部服务框架都由我的团队负责，我们在认真审视如何融合两个框架优点的问题，这一点相信会在未来的 Dubbo 3.0 中有体现。

• 为什么在2年多的“断更”后，选择重启Dubbo开源？

主要缘由有四个方面：战略、社区、生态和回馈。

首先阿里巴巴将开源提到了新的战略高度，去年云栖大会上阿里云宣布了加大技术投入、拥抱开源的策略。

从社区来看，这两年社区提交的 pull request 和问题没有得到及时的解决，一些公司开始自己维护Dubbo的私有分支，使得版本分化严重。所以，Dubbo希望与社区进一步的互动，同时激发 Dubbo 团队的产品灵感。

而一个活跃的社区必将产生一个繁荣的生态，将普惠所有使用 Dubbo 的人和Dubbo本身。

我们目前也在倾听社区里的声音，对版本做升级，希望通过开发者们的共同推动，未来都回馈给社区。

我相信，这次投入资源重启开源核心是让开源发挥更大的社会价值，对于我们 Dubbo 团队来说，也能够从社区的交流中获得更多的灵感。

• 现在重新启动Dubbo是否还有相当的优势与社会认可度？

实践证明，Dubbo 在国内开发社区里还是有很好的群众基础的，很多公司的服务化方案上跑在 Dubbo 上。

自去年开源重启以来，GitHub 上的 star 数增长接近 80%，达到了 18500。当然后面我们需要更加关注 Dubbo 对最新技术趋势的跟随，服务治理的增强，以及对性能的追求。

同时，我们也十分欢迎社区的贡献，并且目前已经和国内一些活跃的 Dubbo 个人开发者和公司建立了紧密的连接，未来我们还期待有国外的开发者能够加入进来。

• 目前Dubbo在Apache的孵化进展如何？选择捐赠的原因是什么？

项目捐赠给 Apache 基金会进行孵化，Dubbo并不是首例，早在2016 年 12 月，阿里巴巴就宣布将移动开源项目 Weex 捐赠给 Apache 基金。

目前，进入 Apache 基金会之后的第一个正式版本的发布正在准备中，由于要熟悉 Apache 的发布过程，这个版本会花些时间，所以还请大家耐心等待一段时间。

而捐献给 Apache 基金会的原因也很简单，这次把项目放到中立方托管，是希望借助社区的力量来发展 Dubbo，也打消大家对于 Dubbo 未来的顾虑。

捐献之后的代码库仍然在 GitHub 上，地址是:https://github.com/Apache/incubator-Dubbo。

另外我们会同步在 https://github.com/Dubbo 上建设 Dubbo 的生态，期望为所有 Dubbo 的使用者带来更丰富的选择。

社区交流基本是英文呈现，是否在重启中考虑建立中文的社区？



社区交流基本上用英文一方面上 Apache 的要求，另一方面我们也期待 Dubbo 能够走向世界。

但同时，我们当然不能够忽略国内用户永远是 Dubbo 最大的用户群体的这个事实，中文社区也在规划之中，会重点包括产品文档、技术博客、和问答社区等。

• 今后的Dubbo开发者沙龙活动在城市选择和内容侧重上如何？

目前看起来，Dubbo 的主要用户分布在北上广深和杭州，进一步的，我们也会重点考虑成都和南京。

沙龙活动的分享主题是面向工程师向的，会包含架构分析、源码解读、Hands On、以及友商案例分享等内容，由于 Dubbo meetup 同时会提供直播，完全可以异地跟踪到 Dubbo meetup 每一站的内容。

谈“微服务架构”

提到 Dubbo 就不能不说微服务 而言及微服务一定有Service Mesh一席之地

传统的微服务向我们展现了服务化的未来蓝图，也提供了诸多方法论和最佳实践指导我们完成架构的变革。

但是显然实施过微服务的朋友们都一定清楚，这是一个异常复杂且充满了不确定性的改造过程——将单体系统剥离、引入服务化组件、将内部调用转化为远程调用、解决因为调用远程化和分布化而带来的各种次生问题（网络问题、安全问题、状态管理问题、一致性问题等等）。

此时，Service Mesh 无疑是一根救命稻草。简言之，Service Mesh 另辟蹊径，在不深入服务内部的情况下，以 Agent 的形式与服务共生，并由 Agent 提供一切微服务所需要的能力。

• 分布式事务如何解决？

采取 BASE 柔性事务，强调最终一致性，相关的手段包括 TCC、可靠消息和补偿机制等。目前这一块的趋势是如何避免对业务的侵入。

原文链接

本文为云栖社区原创内容，未经允许不得转载。