毛剑bilibili（B 站）技术总监负责主站技术部研发管理工作，近十年的服务端研发经验。擅长高性能、高可用的服务端研发，熟悉 Go、Java、C 等语言。在 B 站参与了从巨石架构到微服务的完整转型，包含微服务治理、微服务可用性设计、微服务数据一致性设计、微服务中间件、监控、日志收集、负载均衡和 RPC 框架开发等。

毛剑：从事研发、运维、测试的工程是都应该来了解，因为整个微服务体系不仅仅只是开发。一个应用的上线涉及到运维、测试等，了解了整个体系结构才能在各个环节更早的介入来完善这套分布式的、大规模的服务。

毛剑：长远来看，开发即运维，运维即开发是大趋势，对于传统的开发交付应用给运维，这里面存在一个信息不够完善的同步或者说信息跨节点同步的成本问题，只有开发最清楚自己的应用哪里可能存在风险，哪里不够完善，出问题了应该怎么去快速定位，那么对于运维来说他们最熟悉线上环境、操作系统、网络等综合性的问题。微服务里很关键的一点是服务团队内部自治理，因此通过可靠的 PaaS 的平台来交付应用是很关键的，那么运维也就变成了开发工程师把自己的经验转变成平台，提供平台能力以后再和业务开发来协作配合；

毛剑：同问题 2，Google 内部的 SET 的模式，把测试分为 TE、SET 两个角色，也是为了让测试完成转型，更多的提供测试平台能力，比如 CI 里非常关键的单元测试（小测试），以及集成测试（中测试）、e2e 测试（大测试），都需要 PaaS + RPC Framework 来联动支持，对于测试来说他们有熟悉的测试理念和技能，需要把这种能力通过工具、代码的形式影响开发模式，在应用交付上线前，把 bug 收敛在越早的时间解决；

毛剑：微服务的本质可以参考康威定律，即组织结构决定的软件架构，人和人之间的沟通成本随着组织规模变大而变大 (N* (N-1) / 2)，最终我们都会交付速度、质量来努力。微服务分而治之、自治管理就是优势，劣势主要是带来的更高的复杂度，以及对平台能力的要求，需要不少的投入；

毛剑：2018 年大家津津乐道的微服务话题是服务网格、事件驱动架构、容器原生安全性、GraphQL 和 chaos engineering。我还在关注 service mesh 的方向，service mesh 是一个基础设施层，让服务之间的通信更安全、快速和可靠。有观点认为 2018 年是 service mesh 元年，service mesh 被誉为是下一代微服务架构，是企业扩展、保护和监控应用程序的最佳方式。

毛剑：运维、测试、开发 通用平台的建设和开发投入比较多，比如 PaaS 平台，测试环境治理，中间件，监控平台等等；初期转型微服务可用性会受到比较大的挑战，对于开发微服务 RPC 的人员来说需要具备一定的跨网络设计 API（粗粒度）的能力，比如批量接口等，对于工程的鲁棒性有比较高的要求；对传统意义的职责分工会弱化，需要组织结构上调整来配合。

功能、服务越来越多，如何协调线上运行的各个服务，保障服务的 SLA 是一个很大的挑战。从技术和组织两个角度来看如何突破这些问题，ArchSummit 全球架构师峰会应该能给你答案。识别二维码了解微服务相关实践探索。完整大会日程请点击 【阅读原文】了解。目前大会 9 折报名中，有任何问题欢迎联系票务小姐姐灰灰，联系方式：17326843116 （微信同号）