浅谈微服务框架选型

微服务改造是个综合性的系统工程，涉及研发全流程的各个维度，因此在微服务实施前需要进行一些必要的准备工作，比如从团队、技术上进行一系列的储备，确保微服务实施可以稳步进行。那么首先我们就需要进行微服务框架的选型。

选择和评估一个微服务开发框架时，应该从稳定性、易用性、调试与运维友好性这几个维度来考量。

1. 稳定性和可靠性是第一位的，如果代码质量不高，经常出现一些不太好解释的现象，这样肯定会影响线上服务的可用性。

2. 易用性，首先 API 接口设计要非常简洁明确，没有什么歧义，使用起来非常方便，没有什么大的心智负担。对于一些配置项框架要设置最合理的默认值，如果一个框架有非常多的配置参数，并且都交给用户，美其名曰是给用户灵活性，其实是把复杂和负担留给用户，把简单留给自己，这种框架是极其不负责任的。

3. 调试与运维友好性常常被市面上的大多数微服务开发框架所忽略，很多框架经常号称自己有强大的性能表现，但很少有框架在调试和运维上下工夫，如何让使用框架的人在遇到问题时方便快捷地定位，如何支持业务自定义地添加调试和定位信息，这些都是框架需要考虑的问题。

4. 每种语言背后都有一套完善的语言栈体系，语言栈切换过程中很容易踩到一些坑，同时微服务改造本身也是一个复杂度很高的过程，因此除非有特别的原因，不建议在微服务改造的时候进行语言层面的整体切换和重构，当然个别相对独立且风险可控的子服务，可以考虑语言层面的重构。

5. 最后要考虑功能和性能，功能和性能要能够满足当前业务需求。把这个放在最后是因为绝大多数框架在功能和性能上均能够满足需求。

对于性能评估和性能测试，大家平常一般主要关注 QPS 和耗时这两块。需要强调的是，性能测试前需要确定性能测试的基准，比如 99.9%的响应时间必须在 10ms 之内。后续所有的性能测试需要严格按照这个基准执行。针对 QPS 需要关注框架在多核或多线程下的扩展性；针对耗时，不仅要关注平均耗时，更要观察耗时长尾分布，以及耗时长尾是否有放大效应。