从0到1实现一个模块间通讯的服务组件

写在前面

在一名一线开发对于App架构和组件化的思考 文章中，咱们主要站在了软件工程的角度上，分析了作App架构和组件化时该如何下手，其中也介绍了路由和服务模块在组件化中扮演的重要角色。本文，咱们将进行实操，一步步实现一个模块间通讯的服务组件。

这里剖出一个微服务的概念，在Java Spring框架中，微服务是个很火的东西。鉴于笔者对于Java一律不知，因此仅仅站在做为一个App开发的角度去认知它。微服务确切的说是某个功能模块的子集，它把单体架构中的某些功能拆离出来，而后开启独立进程来给其余模块提供服务，通讯方式通常是标准REST API来进行。这样的作的话有几个好处。

1.独立进程，独立部署。不会由于单体架构机器挂掉后，致使全部服务不可用。
2.避免项目过分臃肿。
3.扩展性强，能够多个微服务组成集群。

对于Java Spring框架，这里就不作过多赘述了。推荐一个比较形象的描述微服务的漫画，感兴趣的能够看一下，这样能够对整个系统上下游架构会有更深的理解。

漫画说：什么是微服务？

服务组件在App里应用场景

举个栗子🌰。
仍是拿登陆模块举例子。。。

在以前的分享中咱们知道，登陆模块通常位于App分层架构中的通用模块层。假如说A模块要调用登陆模块中的获取登陆态的方法，在没有服务组件的状况下，咱们通常会直接把登陆整个模块import进来，这样作不免有点小尴尬（仅仅是获取个登陆态，我就要把整个登陆模块import进来，这样就耦合在一块儿）。

再打个很形象的比喻。。。
虽然说结婚不是两我的的事情，而是两个家庭的事情，可是结婚后你老丈人和丈母娘一块儿打包过来跟你过了，你是什么感觉？那确定是脸上笑嘻嘻，内心mmp啊。我是要跟你女儿过日子的啊，咋都打包给我了？？？😄。

因此经过以上的生动的示例，咱们总结出了服务组件在App里的应用场景。

• 模块间更小粒度组件间的通讯场景。
• 开放一个模块中某些特定功能API场景，使模块中的子组件“微服务化”。
• 组件化之间进行解耦的应用场景。

从0到1编写一个服务组件

方案一：通知中心（NSNotificationCenter）

Excuse me?通知不是单向数据传输么，A给B发通知，B收到通知后处理，貌似不符合咱们这种有返回值的需求啊？

在OC中有个神奇的东西那就是Block，说白了是匿名函数，那咱们直接把函数指针传输过去不就能够了嘛？并且咱们知道在OC中Block本质上是一个对象，刚好发送通知能够携带一个对象，岂不美哉。

- (void)postNotificationName:(NSNotificationName)aName object:(nullable id)anObject;

说写咱就写！Perfect！你为什么如此优秀！！！

登陆模块：

/*登陆模块注册通知*/
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(getCookie) name:@"getCookie" object:nil];  

- (void)getCookie:(NSNotification *)noti {
    void(^callBack)(NSString *) = noti.object;
    /*获取cookie逻辑*/
    ---this is a long story---
    /*获取完毕以后，调用block*/
    if (callBack) {
        callBack(@"cookie");
    }
}
复制代码

调用模块：

/*建立一个Block*/
void(^callBack)(NSString *) = ^(NSString *cookie) {
     NSLog(@"cookie->%@",cookie);
 };
/*调用方经过发送通知*/
[[NSNotificationCenter defaultCenter] postNotificationName:@"getCookie" object:callBack];

复制代码

Command+B，完美！知足需求，咱们成功地在模块中获取到登陆模块中的登陆态。

这时候咱们停下来仔细想一下通知中心的方案，假如说登陆模块除了提供获取登陆态的服务，可能还有获取用户信息服务等等。若是服务愈来愈多，注册通知就会分散在不一样的文件中、不一样的代码逻辑中，服务太分散难以维护！！！

咱们总结了一下，很容易发现通知的方案所存在的问题。

• 注册通知太分散，难以维护。
• 没有统一的地方来维护通知名称，调用方须要预先知道通知名才能调用该服务。
• 传参数不太方便，虽然系统发送通知函数提供了一个object，但在复杂业务中远远不够。
• 通知中心存在必定的问题，好比说不支持异步通知（在A线程注册通知，B线程发送通知，接收到通知后回到A线程进行处理）。

关于通知中心的弊端，这里也不作赘述，推荐一个本身以前写的一个通知中心解决方案，目前还不太完善。其使用姿式至关优雅，并且实现了异步通知，感兴趣的筒子们能够了解一下。

SmartBlock（一个用Block实现的通知替代方案，而且已实如今不一样线程进行发送消息和执行Block，支持多参数传送，解决回调地狱问题，适用于组件化数据传输等。）

方案二：反射机制（NSClassFromString）

名词解释：Java反射说的是在运行状态中，对于任何一个类，咱们都可以知道这个类有哪些方法和属性。对于任何一个对象，咱们都可以对它的方法和属性进行调用。咱们把这种动态获取对象信息和调用对象方法的功能称之为反射机制。以上内容来自于网上。

在OC中，runtime也提供了相似的机制，咱们能够经过runtime提供的函数，在运行时动态地获取到某个类、方法、属性等。

NSClassFromString(<#NSString * _Nonnull aClassName#>) NSSelectorFromString(<#NSString * _Nonnull aSelectorName#>)

既然方案一注册通知太分散，那咱们可不能够对于每一个服务建立一个类，而后暴露方法，经过runtime反射机制去调用？

• 第一步：针对获取登陆态的服务单首创建类文件。
• 第二步：在类文件中开放一个方法供调用方调用。
• 第三步：调用方经过NSClassFromString获取到登陆态的Class。
• 第四步：调用方经过NSSelectorFromString获取到登陆态提供的selector。
• 第五步：调用该方法- (id)performSelector:(SEL)aSelector withObject:(id)object;完成该服务的调用。

登陆模块：

/*咱们在登陆模块建立一个GetLoginCookie类*/
/*.h和.m以下*/
复制代码

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface GetLoginCookie : NSObject

- (id)getLoginCookieWithObjc:(id)obj;

@end

NS_ASSUME_NONNULL_END
复制代码

#import "GetLoginCookie.h"

@implementation GetLoginCookie

- (id)getLoginCookieWithObjc:(id)obj {
    return @"cookie";
}

@end
复制代码

调用模块：

/*在模块中获取到GetLoginCookie的Class*/
Class cookieCls = NSClassFromString(@"GetLoginCookie");

/*经过Class，生成一个GetLoginCookie实例*/
id cookieInstance = [[cookieCls alloc]init];

/*经过方法名生成一个SEL*/
SEL selector = NSSelectorFromString(@"getLoginCookieWithObjc:");

/*调用performSelector并获取返回值*/
NSString *cookie = [cookieInstance performSelector:selector withObject:@"it's me!"];
NSLog(@"cookie->%@",cookie);

复制代码

Command + B，完美运行，咱们也获得了咱们想要的结果。

对比方案一和方案二，方案二的确解决了服务分散很差管理的问题，可是依然存在几个问题。

• 依然没有一个配置的地方让调用者一下就能看到类名或者sel名，方便进行调用。
• 还有个问题，咱们很容易发现这两个方案都是**“去中心化的”**。也就是说，消息的发送和消息的接收处理都是直接点对点的。去中心化带来了不少问题，若是登陆态的服务出现问题，而咱们又没有一个统一收口的地方统一处理，不可控。

这就比如区块链技术去中心化虽然带来了不少技术变革，但一样也带来了一些隐患。若是没有上面的👆的监管，那不少black money💰能够经过区块链手段洗到国外。想一想不少贪官拿着咱们辛辛苦苦缴纳的税，把贪来的钱都洗到了国外，而后老婆孩子在国外逍遥自在，本身在国内作luo官。而咱们依然活在水深火热之中，百姓民不聊生，苦不堪言，咱们心里该是何等气愤！！！😓。

扯多了，咱们回到正题。😄

方案三：引入中间件（IQService）

经过对比前两个方案，咱们大概对于服务组件应该知足哪些要素有了更加清晰的认识。

• 服务组件要易于管理，统一分布在模块中的某个地方。
• 服务组件最好经过配置文件去管理，方便业务方查阅调用等。
• 服务组件去Model化，完全解除、还有支持同步异步调用等。
• 服务组件最好用中间件方式，有统一收口的地方，发生问题可控。
• 服务组件最好支持静态注册、动态注册等，扩展性高。

咱们来简单画一下，服务组件架构图。

• 首先为了解决服务易于管理问题，咱们这里使用plist来维护业务服务列表和具体服务名与服务的对应关系。

如图所示，IQService.plist维护了业务list，通常IQService主工程维护一份便可。

LoginModule.plist中维护了该组件为外部提供的全部服务列表（服务名和实现类的对应关系）

• 去model化，咱们这里用多参数来解决（也能够经过NSDictionry解决）。

/**
 同步、异步调用

 @param sevice 微服务名
 */
+ (void)invokeMicroService:(NSString *)sevice,...;

/**
 同步调用

 @param service 微服务名
 @return 同步调用返回值
 */
+ (id)invokeMicroServiceSync:(NSString *)service,...;

复制代码

咱们再来看下具体的使用姿式。

登陆模块：

首先建立LoginModuleCookieService类，并将该类注册到LoginModule中。

复制代码

.h声明
#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface LoginModuleCookieService : NSObject

- (NSString *)getCookieWithSignature:(NSString *)signature;

@end

NS_ASSUME_NONNULL_END
复制代码

.m实现
#import "LoginModuleCookieService.h"

@implementation LoginModuleCookieService

- (NSString *)getCookieWithSignature:(NSString *)signature {
    return [NSString stringWithFormat:@"%@->cookie",signature];
}

@end
复制代码

调用模块：

同步调用
NSString *cookie = [IQService invokeMicroServiceSync:@"GetCookieSyncService",@"我是同步调用",nil];
NSLog(@"%@",cookie);
复制代码

异步调用
void (^callBack)(NSString *) = ^(NSString *cookie){
        NSLog(@"%@",cookie);
    };
[IQService invokeMicroService:@"GetCookieAsyncService",@"我是异步调用",callBack,nil];
复制代码

分析到如今，方案三基本能知足大部分业务需求。具体实现代码已经开源到GitHub -----> IQService，一个iOS端模块间通讯的解决方案。喜欢的筒子能够来波Star❤️，也欢迎你们提交PR和ISSUE。

骗你们刷完Star，如今再泼盆冷水。。。😅
咱们再仔细思考一下方案三，貌似有几个问题依然没有解决

1.编译时依然没法进行参数正确性校验，attribute？宏定义？
2.目前只有静态注册，不支持动态注册。

上面两个问题，欢迎你们进行头脑风暴。有好的解决方案能够留言分享，也能够提交PRs or Issues。github.com/Lobster-Kin…。

在这里提示一点，没有一个方案是100%OK的，只有适合本身的才是最好的。😄

架构和组件化系列文章预告：说说MVVM，会一步步跟你们写一个轻量的view和viewModel进行数据绑定的框架。

文章首发GitHub github.com/Lobster-Kin…