面向服务架构~面向服务的API是统一接口还是具体业务使用具体的接口?

简介:

前言说明:这里说的"接口"并不是C#时的interface,而一般指定一个方法签名,它一般为外部提供一个GET请求,接口到请求后,进行处理,然后对调用方进行信息的返回.

回到本题中来,事件上,我们坐下来,认真去想想,还是统一接口的比较好,如果要具体业务使用具体接口,那它的具体接口肯定也是去再调用一下"那个统一的入口模块"的,注意,这里我说的是"模块",而不是"接口,类,方法等"

大体流程应该是这样:

客户端调用某个服务接口

接口系统

调用某体业务前的逻辑

    创建一个具体业务

调用某体业务后的逻辑

返回给客户端


对于一个服务端的代码要求应该是这样:

1 接口对外具有稳定性

2 对自己具体很好的扩展性(开闭原则)

3 每种具体业务都是独立的(单一职责原则)

对于上述要求,我设计如下代码:

 1     /// <summary>
 2     /// 对外统一接口模块
 3     /// </summary>
 4     public class SOA : Controller
 5     {
 6         /// <summary>
 7         /// 统一接口方法,外面可以使用GET请求
 8         /// </summary>
 9         /// <param name="blockName"></param>
10         /// <param name="param"></param>
11         /// <returns></returns>
12         public ContentResult UserAPI(string blockName, string param)
13         {
14             IAPI create = (IAPI)System.Reflection.Assembly.Load("dll").CreateInstance("namespace" + blockName);
15             if (create.Create(param))
16                 return Content("成功");
17             else
18                 return Content("失败");
19         }
20     }
21 
22     /// <summary>
23     /// 建立API指定接口规范
24     /// </summary>
25     internal interface IAPI
26     {
27         bool Create(string param);
28     }
29 
30     /// <summary>
31     /// 添加购买动态的服务
32     /// </summary>
33     internal class AddBuyingNews : IAPI
34     {
35         public bool Create(string param)
36         {
37             return true;
38         }
39     }
40 
41     /// <summary>
42     /// 添加用户等级的服务
43     /// </summary>
44     internal class AddUserLevel : IAPI
45     {
46         public bool Create(string param)
47         {
48             return true;
49         }
50     }

通过上面代码,我们可以看到,对外统一UserAPI是稳定的,当业务有变化直接修改具体业务即可,客户端平台不用修改,而AddBuyingNews和AddUserLevel这两个类型是实现各自业务的,它们之间是独立的,功能是单一的,这符合单一职责,而如果服务层希望扩展新的业务只要建立一个新类型即可,对外统一接口UserAPI不用改变,因为具体业务已经通过反射实现了松耦合,有人说反射会对性能有很大的影响,事实上,不是这样的,细心的朋友可以看一下.net自己的托管的类库,用了大量的反射,为何要用反射?我会在另一篇文章中去说明,今天主要讲的就是这些,呵呵.

本文转自博客园张占岭(仓储大叔)的博客,原文链接:面向服务架构~面向服务的API是统一接口还是具体业务使用具体的接口?,如需转载请自行联系原博主。

相关文章
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
113 8
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
微服务架构下的API网关设计策略与实践####
本文深入探讨了在微服务架构下,API网关作为系统统一入口点的设计策略、实现细节及其在实际应用中的最佳实践。不同于传统的摘要概述,本部分将直接以一段精简的代码示例作为引子,展示一个基于NGINX的简单API网关配置片段,随后引出文章的核心内容,旨在通过具体实例激发读者兴趣,快速理解API网关在微服务架构中的关键作用及实现方式。 ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_service:5000;
探索微服务架构下的API网关设计与实践
在数字化浪潮中,微服务架构以其灵活性和可扩展性成为企业IT架构的宠儿。本文将深入浅出地介绍微服务架构下API网关的关键作用,探讨其设计原则与实践要点,旨在帮助读者更好地理解和应用API网关,优化微服务间的通信效率和安全性,实现服务的高可用性和伸缩性。
75 3
探索微服务架构中的API网关设计
在微服务架构的复杂性中,API网关作为客户端和后端服务间的桥梁,扮演着至关重要的角色。本文将深入探讨如何设计一个高效、可扩展且安全的API网关,包括处理请求转发、负载均衡、身份验证、监控与日志记录等核心功能,并讨论如何在保障性能的同时确保系统的高可用性和安全性。通过具体案例,我们将了解API网关在实际生产环境中的实现方式及其对整个微服务生态系统的影响。
93 3
微服务架构下的API网关设计与实现
在分布式系统和微服务架构中,API网关扮演着至关重要的角色。它不仅是服务的单一入口点,还负责请求的路由、负载均衡、认证授权、限流熔断等关键功能。本文将深入探讨API网关的设计理念、核心组件以及实现策略,旨在为开发者提供一套完整的API网关解决方案。通过分析现代微服务架构的需求,结合最新的技术趋势,我们将展示如何构建一个高效、可靠且易于维护的API网关。
99 0
微服务架构下的API网关设计
【6月更文挑战第14天】本文将深入探讨微服务架构中的核心组件——API网关,分析其在系统设计中的重要性和实现策略。我们将通过一个具体的案例,展示如何构建一个高效、可扩展的API网关,以满足现代应用程序的需求。
61 3
微服务架构下的API网关设计实践
【6月更文挑战第15天】本文将深入探讨在构建现代软件系统时,如何有效地设计和实现一个API网关。我们将从API网关的核心作用出发,分析其在不同场景下的应用,并结合实际案例,展示如何通过API网关提升系统的可扩展性、安全性和性能。文章旨在为后端开发人员提供一套清晰的指南,帮助他们在微服务架构中实现高效且可靠的API管理策略。
微服务架构下的API网关设计与实践
【6月更文挑战第11天】在现代软件开发中,微服务架构因其灵活性和可扩展性而受到青睐。作为微服务系统的入口,API网关承担着请求路由、负载均衡、安全认证等关键职责。本文将深入探讨API网关的设计要点与实践策略,旨在为读者提供构建高效、稳定API网关的实用指南。
构建高效微服务架构:API网关的设计与实践
【5月更文挑战第20天】 在微服务架构中,API网关作为系统入口,承担着请求路由、负载均衡、权限校验等关键职责。本文将深入探讨如何设计一个高性能且易于扩展的API网关,并分享在实际项目中的实践心得。通过分析API网关的核心组件和常见挑战,我们将讨论优化策略,包括但不限于缓存机制、限流算法以及服务熔断。文章最终旨在提供一套可行的解决方案,帮助开发者构建出既健壮又灵活的后端服务架构。
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等