认识达内从这里开始

微服务框架开发可以说是目前比较热门的一种开发方式了。今天，我们就通过案例分析来了解一下，微服务框架都具备了哪些功能以及优点和缺点的对比。

一、微服务框架应具备的功能

1、API Gateway：

实现一个API网关作为所有客户端的入口。API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上，其他的请求被转给到一组服务

相比于提供普适的API，API网关根据不同的客户端开放不同的API。比如，Netflix API网关运行着客户端特定的适配器代码，会向客户端提供适合其需求的API。

API网关也可以实现安全性，比如验证客户端是否被授权进行某请求。

2、负载均衡：

同时部署多套对等微服务和数据库，科学规划负载均衡算法，支持在API Gateway层对请求进行分发处理。

3、认证和鉴权：

支持统一认证和鉴权机制，通过管理和应用Token来实现认证和鉴权。

4、日志和审计：

框架一方面要记录重要的框架层日志、metrics和调用链数据，还要将日志、metrics等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理

5、统一错误处理：

对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。

6、REST/RPC和序列化(通信方式)：

框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来，HTTP/REST是当前主流API暴露方式，在性能要求高的场合则可采用Binary/RPC方式。

针对当前多样化的设备类型(浏览器、普通PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出Ajax友好的JSON消息格式，而对无线设备上的Native App，框架支持输出性能高的Binary消息格式。

7、配置：

除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。

8、安全处理封装：

安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。

9、消息总线：

轻量级的MQ或HTTP。

10、监控和告警：

主要是监控每个服务的状态，必要时产生告警

11、分布式管理(包括微服务和数据库)：

对微服务和数据库均支持分布式处理，微服务和数据库之间支持多对多组合应用。

12、微服务CI/CD流水线：

支持持续集成和持续部署，能够到DevOps一体化运维标准。

13、服务治理：

按需伸缩：部署与监控运维成本

独立部署：机器数量与部署成本

业务独立：服务依赖、治理，版本管理、事务处理

技术多样性：环境部署成本、约定成本

运行状态治理：监控、限流、SLA、LB、日志分析

部署：快速、复制、扩容;单机开发

调用：安全、容错、服务降级、调用延时

14、服务注册及发现：

提供服务注册及发现相应管理功能。

服务注册(客户端发现)：

提供统一服务注册中心，可以对所有服务进行跟踪及管理。

15、管理接口：

框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。

16、限流和容错：

框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。

17、事件调度机制：处理事件机制。

18、资源管理：

提供相关的资源管理功能。如：底层的虚拟机，物理机和网络管理。

19、统一代码框架：

提供统一框架，支持多种语言的运用。

20、统一服务构建和打包：

提供统一的管理机制对微服务进行构建和打包。使微服务的构建和打包标准化进行，也便于微服务间的交互。

21、统一服务测试：

提供统一的测试机制及工具，屏蔽服务内部的差异，可对微服务进行标准化测试。

22、服务依赖关系管理：

提供统一的管理机制及功能，采用科学、合理的管理策略来管理众多服务及相互依赖。例如分组、分层等。

23、统一问题跟踪调试框架，俗称调用链：

提供统一跟踪调试微服务的工具，可以方便的对调用链上的微服务进行跟踪和调试。

24、灰度发布：

支持产品发布的平滑演进，逐步扩大覆盖范围，通常也叫灰度放量。

25、蓝绿部署：

支持新旧版本的在线切换。

二、微服务框架的优点

1、复杂度可控：

将整体应用程序分解成一组服务，服务粒度按需可控，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。

2、独立开发和演化：

技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。

开发人员可以自由选择任何有用的技术，可以独立的开发和演化所负责的服务，因为服务相对较小，使使用新技术重写服务变得可能。

3、独立部署：

每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。

4、独立按需扩展：

每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。

比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。

5、技术选型灵活：

微服务可通过佳及合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。

6、容错及高可用：

通过负载均衡配置，可以实现微服务容错。

微服务架构方式是松耦合的，可以提供更高的灵活性。

微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

三、微服务框架的缺点

1、运维开销及成本增加：

整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。

2、必须有坚实的DevOps开发运维一体化技能：

开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。

3、隐式接口及接口匹配问题：

把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。

在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。

4、代码重复：

某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。

5、分布式系统的复杂性：

作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如跟踪问题困难、网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，

开发人员需要考虑以上的分布式系统问题。

6、异步机制：

微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。

7、可测性的挑战：

在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。

但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

8、数量大管理复杂：

当服务数量增加，管理服务的复杂度大幅提升，需要合理、科学的建立服务的注册、发现、监控等机制。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。