前言
前事不忘后事之师，本篇博客是在拜读和学习了杨波的《微服务架构技术栈选型手册》后结合自己的整理和思考。
https://www.infoq.cn/article/micro-service-technology-stack/
随着IT技术发展和推进，传统的单体应用程序模式已不满足大多数企业IT平台构建，尤其是大型互联网网站或企业级应用。单体应用随着项目持续集成，代码库越来越大，在系统复杂度、测试、代码冲突解决、可扩展性、多环境支持、需求变更容易造成系统整体影响等方面面临各种严峻挑战。此时微服务架构应运而生。
微服务从2014的1.0技术元年开始，随着微服务社区的推进，微服务技术体系生态产生极大变化，微服务进入2.0时代。微服务架构体系经过多年的大规模生产验证，已成为构建大型互联网网站、大型企业级应用的首选分布式技术架构。
相对於单体应用，微服务更具有优势：
- 易于理解：微服务将应用按照功能分解为独立开发和部署的微型应用，每个服务与应用程序的其他微服务之间有一个很小且有限的契约。微服务更加专注目标，作为一个功能模块的单元，微服务更容易理解。
- 微服务易于测试：每个微服务都是独立开发部署的微型应用，易于测试。在集成测试和验收测试方面也更易于验证。
- 较少遇到库不兼容问题：每个微服务都有自己独立的项目构建依赖项的集合，而这些集合不会与其他微服务共享。
- 微服务能够独立扩展：微服务之间独立部署，因此指定微服务的内存和实例扩展不会影响整体应用其他微服务的内存和实例数量。
- 微服务可以独立选择不同的技术栈：微服务可以选择不同的语言、平台、框架和库。特别是如果微服务采用HTTP协议这样的跨平台协议，实际上java微服务可以和C#、Python等编写的微服务协作是完全合理的。
- 微服务更易于发布：微服务是独立部署的，因此不需要等待其他微服务部署就绪。同时随着k8s、Dockers这样的容器化、自动化部署工具的出现，让微服务的发布更加简单。
微服务架构作为分布式架构，同样面临网络延迟、多服务运维、分布式复杂性等问题的挑战，如何保证微服务的构建、发布、运维管理，合理的微服务技术栈选型是重中之中。
选型准则
生产级
我们使用微服务架构是要解决实际业务场景和生产抗流量的，而不是做简单的demo，如果选择不慎可能出现生产级事故。因此，生产级（Production Ready）、可运维（Ops Ready）、可治理、技术成熟的微服务技术才是我们的首选。
使用已经在多个一线互联网或大型企业落地并经过生产挑战的
我们应该尽量选择使用已经在多个一线互联网或大型企业落地并经过生产挑战并且开源的，且在社区有良好口碑的技术栈。
开源社区活跃
社区活跃、stars数量越多、代码和文档更新频率高的技术栈是优选选择的，开源社区活跃可以直接反应技术的生命力。
结合项目实际情况
不是所有项目都适用于微服务架构体系，多余研发团队较少、应用日流量少的业务体量和企业应该慎重考虑是否使用微服务构建项目。微服务架构主要还是针对高并发、高日流量、研发团队规模较大且有独立的运维团队这样的大型业务平台或团队。同时针对团队技术能力，选择合适的微服务架构也是很有必要。
微服务基础架构关键
微服务2.0架构核心模块
微服务总体架构
微服务框架选型
微服务框架经过多年发展是一个比较成熟的领域，有比较多选择，以下为市场主流微服务架构对比：
| 功能点/微服务框架 | Spring Boot/Cloud | Dubbo/DubboXg | gRpc | Thirft | Motan |
| 功能点位 | 完整微服务框架方案 | 服务框架 | RPC | RPC | RPC |
| 是否支持REST | 是，基于Ribbon支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 |
| 是否支持RPC | 否 | 是 | 是 | 是 | 是 |
| 是否支持多语言 | 是 | 否 | 是 | 是 | 否 |
| 典型案例 | Netflix | 阿里、当当 | 谷歌 | Sina | |
| 社区活跃 | 高 | 高 | 高 | 一般 | 一般 |
| 文档丰富度 | 高 | 高 | 一般 | 一般 | 一般 |
Spring Boot/Cloud由于其Spring社区影响和Netflix的背书，以及其提供的完整一套微服务框架实现方案，目前可以认为是基于java构建微服务的标准方案。其对于新兴团队或未形成自己微服务体系的团队有较大吸引力。
Spring Boot/Cloud框架本身基于HTTP协议，是一种典型的RESTfull框架而不是RPC框架，序列化协议主要基于文本的JSON。
RESTfull天然支持跨语言平台，任何支持HTTP协议的应用都可以接入调用，但是客户端需要自己解析payload。