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

2019-05-06 本文已影响362人一线搬砖工人

写在前面

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

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

1.独立进程，独立部署。不会因为单体架构机器挂掉后，导致所有服务不可用。
2.避免项目过度臃肿。
3.扩展性强，可以多个微服务组成集群。

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

漫画说：什么是微服务？

服务组件在App里应用场景

举个栗子。
还是拿登录模块举例子。。。

image

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

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

image

所以通过以上的生动的示例，我们总结出了服务组件在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化，彻底解除、还有支持同步异步调用等。
服务组件最好用中间件方式，有统一收口的地方，发生问题可控。
服务组件最好支持静态注册、动态注册等，扩展性高。

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

app-service-architecture.png

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

image

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

image

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。https://github.com/Lobster-King/IQService。

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

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

文章首发GitHub https://github.com/Lobster-King/AppArticles

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

写在前面

服务组件在App里应用场景

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

猜你喜欢

热点阅读