微服务架构技术栈选型指南[001].docx

PAGE PAGE1 微服务架构技术栈选型指南 微服务架构技术栈选型指南 2014年可以认为是微服务1.0的元年，当年有几个标志性事件，一是MartinFowler在其博客上 发表了”Microservice”s一文，正式提出微服务架构风格；二是Netflix微服务架构经过多年大规 模生产验证，最终抽象落地形成一整套开源的微服务基础组件，统称NetflixOSS，Netflix的成功经验开始被业界认可并推崇；三是Pivotal将NetflixOSS开源微服务组件集成到其Spring体系，推出SpringCloud微服务开发技术栈。 一晃三年过去，微服务技术生态又发生了巨大变化，容器，PaaS，CloudNative，gRPC，ServiceMesh，Serverless等新技术新理念你方唱罢我登场，不知不觉我们又来到了微服务2.0时代。 基于近年在微服务基础架构方面的实战经验和平时的学习积累，我想总结并提出一些构建微服务2.0技术栈的选型思路，供各位在一线实战的架构师、工程师参考借鉴。对于一些暂时还没有成熟开源产品的微服务支撑模块，我也会给出一些定制自研的设计思路。 二、选型准则 对于技术选型，有很多标准，其中下面三项是最重要的： 生产级 我们选择的技术栈是要解决实际业务问题和上生产抗流量的（选择不慎可能造成生产级事故），而不是简单做个POC或者Demo展示，所以生产级（ProductionReady），可运维（OpsReady），可治理，成熟稳定的技术才是我们的首选； 一线互联网公司落地产品 我们会尽量采用在一线互联网公司落地并且开源的，且在社区内形成良好口碑的产品，它们已经在这些公司经过流量冲击，坑已经基本被填平，且被社区接受形成一个良好的社区生态（本文附录部分会给出所有推荐使用或参考的开源项目的GitHub链接）。 开源社区活跃度 GitHub上的stars的数量是一个重要指标，同时会参考其代码和文档更新频率（尤其是近年），这些指标直接反应开源产品的社区活跃度或者说生命力。 另外，对于不同业务体量和团队规模的公司，技术选型标准往往是不同的，创业公司的技术选型和BAT级别公司的技术选型标准可能完全不同。本文主要针对日流量千万以上，研发团队规模不少于 50人的公司，如果小于这个规模我建议认真评估是否真的需要采用微服务架构。考虑到Java语言在国内的流行度和我个人的背景经验，本文主要针对采用Java技术栈的企业。本文也假定自建微服务基础架构，有些产品其实有对应的云服务可以直接使用，自建和采用云服务各有利弊，架构师需要根据场景上下文综合权衡。 这里编辑强力推荐杨波在『极客时间App』上的微服务架构视频白板课程，他用一张图，6分钟时间，深入浅出解释微服务架构中的关键概念。目前是第一季，后面还有第二季。感兴趣的用户还请点击文末阅读原文链接了解详情。 三、微服务基础架构关键点 下面脑图中芒果色标注的七个模块，我认为是构建微服务2.0技术栈的核心模块，本文后面的选型会分别基于这些模块展开。对于每个模块我也列出一些核心架构关注点，在选择具体产品时，需要尽可能覆盖到这些关注点。 下图是我近期工作总结和参考的一个微服务技术体系，我想同时分享给一线架构师或者工程师参考，其中粉红色标注的模块是和微服务关系最密切的模块，大家在做技术选型时，可以同时对照这个体系。 4 PAGE PAGE10 四、服务框架选型 服务框架是一个比较成熟的领域，有太多可选项。SpringBoot/Cloud[附录12.1]由于Spring社区的影响力和Netflix的背书，目前可以认为是构建Java微服务的一个社区标准，SpringBoot目前在GitHub上有超过20k星。 基于Spring的框架本质上可以认为是一种RESTful框架（不是RPC框架），序列化协议主要采用基于文本的JSON，通讯协议一般基于HTTP。RESTful框架天然支持跨语言，任何语言只要有HTTP客户端都可以接入调用，但是客户端一般需要自己解析payload。目前Spring框架也支持Swagger契约编程模型，能够基于契约生成各种语言的强类型客户端，极大方便不同语言栈的应用接入，但是因为RESTful框架和Swagger规范的弱契约特性，生成的各种语言客户端的互操作性还是有不少坑的。 Dubbo[附录12.2]是阿里多年构建生产级分布式微服务的技术结晶，服务治理能力非常丰富，在国内技术社区具有很大影响力，目前github上有超过16k星。Dubbo本质上是一套基于Java的RPC框架，当当Dubbox扩展了Dubbo支持RESTful接口暴露能力。 Dubbo 主要面向Java技术栈，跨语言支持不足是它的一个弱项，另外因为治理能力太丰富，以至于这个框架比较重，完全用好这个框架的门槛比较高，但是