框架的选型要满足可移植性、可维护性、可测试性。
| 指标定义 | 说明 |
|---|---|
| 可移植性 | 技术平台在设计和实施过程中采用标准接口 |
| 健壮性 | 平台提供完备的服务故障容错保护功能，保证平台的健壮性。 |
| 可维护性 | 基于多方面进行可维护性设计，提高部署和维护的效率，在发生故障后，平台的运维人员可以快速进行定位并排除障碍 |
| 可测试性 | 平台提供进行功能、性能、压力和集成等各个方面的测试的配合能力。 |
一、微服务
微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
1.1 微服务的优点：
1.降低复杂度
将原来偶合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能。
2.可独立部署
由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。
3.容错
在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。 通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。
4.扩展
单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。
1.2 微服务的缺点：
1.团队沟通的过载
微服务架构降低了团队管理的难度，但是确不能降低团队沟通的需求。
2、正式文档的过载
每一个独立的运行部件需要持续维护其规格和接口文档，这些文档是其它团队使用这些部件的必要条件。
3、不一致性
我们可以为每一个组件选择不同的技术栈。这导致了不一致的应用设计和架构，而这会在更长期的运维期间增加系统维护成本。
4、DevOps的复杂度
我们需要拥有一支成熟的DevOps团队去处理微服务架构的应用的复杂性。
5、资源使用
运行这些微服务架构的应用的初始投资会比较大。
6、网络通信开销
分布式系统的产生的网络开销比单机应用多很多。需要更加可靠和快速的网络连接。
7、编码和解码
这个容易理解，也会产生性能问题。
8、网络安全
通过网络进行通信的系统更容易产生安全缺陷。
9、测试
测试微服务架构的应用绝对比单体应用难很多。
10、产品监控
监控微服务架构应用的成本会更高，很难获得合适的工具，需自研。
二、Dubbo
Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，就是个远程服务调用的分布式框架。
2.1 Dubbo优点
1.Dubbo 支持 RPC 调用，服务之间的调用性能会很好。
2.支持多种序列化协议，如 Hessian、HTTP、WebService。
3.Dobbo Admin后台管理功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。
4.在国内影响力比较大，中文社区文档较为全面。
5.阿里最近重启维护。
2.2 Dubbo缺点
1.注册中心严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断。
2.Dubbo 只支持 RPC 调用。使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错，并且以后发布部署会成很大问题（太强的依赖关系）。
3.Dubbo 只是实现了服务治理，其他微服务框架并未包含，如果需要使用，需要结合第三方框架实现（比如分布式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra，但使用相对麻烦些），开发成本较高，且风险较大。
4.社区更新不及时（虽然最近在疯狂更新），但也难免阿里以后又不更新了。
5.主要是国内公司使用，但阿里内部使用 HSF，相对于 Spring Cloud，企业应用会差一些。
三、Spring Cloud
Spring Cloud 基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。
3.1 Spring Cloud优点
1.有强大的 Spring 社区、Netflix 等公司支持，并且开源社区贡献非常活跃。
2.标准化的将微服务的成熟产品和框架结合一起，Spring Cloud 提供整套的微服务解决方案，开发成本较低，且风险较小。
3.基于 Spring Boot，具有简单配置、快速开发、轻松部署、方便测试的特点。
4.支持 REST 服务调用，相比于 RPC，更加轻量化和灵活（服务之间只依赖一纸契约，不存在代码级别的强依赖），有利于跨语言服务的实现，以及服务的发布部署。另外，结合 Swagger，也使得服务的文档一体化。
5.提供了 Docker 及 Kubernetes 微服务编排支持。
6.国内外企业应用非常多，经受了大公司的应用考验（比如 Netfilx 公司），以及强大的开源社区支持。
3.2 Spring Cloud缺点
1.支持 REST 服务调用，可能因为接口定义过轻，导致定义文档与实际实现不一致导致服务集成时的问题（可以使用统一文档和版本管理解决，比如 Swagger）。
2.另外，REST 服务调用性能会比 RPC 低一些（但也不是强绑定）
3.Spring Cloud 整合了大量组件，相关文档比较复杂，需要针对性的进行阅读。
四、Service Mesh
主要解决：日志记录、监控、流量控制、服务注册、服务发现、服务限流、服务熔断、鉴权、访问控制和服务调用可视化等。
4.1 主机独立进程代理
代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡，如下图所示。这个模式一般也需要独立的服务注册中心组件配合。
Service Mesh又称为服务网格，本质上就是我们前面介绍过的主机独立进程代理。之所为称之为服务网格是因为按照其结构，每个主机上同时运行了业务逻辑代码和代理，此时这个代理被形象地称之为SideCar（业务代码进程相当于主驾驶，共享一个代理相当于边车），服务之间通过SideCar发现和调用目标服务，从而形成服务之间的一种网络状依赖关系，然后通过独立部署的一种称之为控制平面（ControlPlane）的独立组件来集中配置这种依赖调用关系以及进行路由流量调拨等操作，如果此时我们把主机和业务逻辑从视觉图上剥离，就会出现一种网络状的架构，服务网格由此得名。
4.2 Service Mesh的优势
它是纯分布式的，没有单点的问题，性能也比较优秀并且与开发语言无关，还可以集中进行治理。此外，随着微服务化、多语言和容器化的发展趋势，很多公司也迫切需要一种轻量级的服务发现机制，加上一些大厂如Google/IBM的助推（如kubernetes与Docker的容器之争），正好Service Mesh迎合了这种趋势，所以才有今天火热的局面。
（1）应用内部不必再嵌入复杂的微服务Client：应用不再
涉及框架相关的服务发现等功能，每个接口仅需配置一个本地地址进行调用，不必知道集群的情况。
（2）语言无关：由于不需嵌入语言特定的Client，使用标准协议通信的双方均可由任意语言编写，即使是外采的二进制系统，也可以简单的嵌入集群中。
（3）大量减少应用间连接数：同一主机的调用方所涉及的连接可以被Proxy连接复用，因此应用间连接数可大幅减少。
（4）大量减少数据库连接数：原因同上，可以避免微服务带来的数据库连接数爆炸问题。
（5）提升通信加密的效率：可以将通信加密统一放置于由高运行性能语言编写的Proxy上，而非由运行效率较低的应用来进行。
（6）调用过程的集中诊断：由于请求均通过Proxy进行，可以便利的进行统计并收集日志、报文等。
（7）运维控制的统一认证和调度：由于服务发现和调用路由放置在了独立的系统中，运维可以完全掌控调用的过程，包括设置调用的路径，调用权限等。
（8）容器友好：service mesh框架同K8S等编排系统集成度较高，可无缝协同运行。
（9）实施便利：在mesh部署完成后，应用仅需退回原始的直接调用模式即可使用mesh带来的收益。
4.3 Service Mesh的问题
ServiceMesh还在演进中，生产落地仍有挑战，一般企业不建议生产级使用。
- 增加的复杂性: 在一个已经很复杂的环境中引入代理、sidecar和其他组件会极大地增加开发和运维的复杂性。
- 需要的专业知识: 在容器编排器(如Kubernetes)之上添加Istio之类的服务网格通常需要运维人员成为这两种技术的专家。
- 延迟: 服务网格是一种入侵的、复杂的技术，它能向服务架构中添加显著的延迟。
- 平台的依赖性: 服务网格的侵入性迫使开发人员和运维人员适应一个高度自治的平台，并遵守其规则。
