项目的API越来越多了,错综复杂,很多API管理混乱,不知道什么应用调用了什么API,每个API的数据具体如何。。这个时候,天空出现了三个字“SOA”。。什么是SOA,我的理解简单来说就是把服务做成分布式, 高可用,可统计的这么一个玩意,俗称面向服务架构体系。
那怎么实践SOA呢?
有现成的, 例如 dubbo, Consul, Thrift(姑且算是有点沾边吧,实际上这玩意是多语言之间的RPC,可以配合搞可用储存做SOA的机型)。 现在国内比较热的应该是 dubbo,是阿里做的, 之前用过一下,但是这玩意功能是强大, 不过客户端语言貌似只支持 java, C++,现在咱们项目的技术栈主流是PHP, golang所以暂时不考虑了,而且个人觉得有点臃肿,可能因为功能很强大吧。。。。
Thrift 也是一个选择, 可以配合 Zookeeper来架构一个SOA的基形, 而且支持N种语言, 性能也不错
Consul国外挺多人貌似评价不错, 不过个人没玩过,不太了解。。
我们这次选择尝试自己做一个轮子, 做一个SOA的基形,功能慢慢再加上去吧。
下面是我们整个的模块架构
目前我们的项目架构基本就是这样, 不同的API散落在不同的服务器上, 因为原来有各个端,所以PHP一套, java一套, golang也一套,我们先打算把API整理好,主要达到下面的目的。
1. 梳理各个API服务,根据访问的流量考虑, 合理分配到不同的服务器
2. 统计各API的流量情况, 供应者是谁(就是哪台服务器), 消费者是谁(就是哪个应用调用了)
3. 接口透明化, 以后要做一个API都要问问身边的同事, 接口地址多少啊? URL多少啊?之类的,现在直接把这块封装到 一个叫注册中心的玩意里面, 直接用 模块/服务名称 这样的形式调用
4. 多语言一个玩, 可以java写服务,PHP调用, 或者换过来,或者选其他语言等等
整体的技术架构
1. 因为是工作上用到,初期第一版的注册中心先用mysql,本来已经做好了集群了(本来想选用ZK的,但是考虑到增加运维不必要的压力,mysql完全够用了)
2. provider通信这块先用golang试下水做做, 看看性能如何吧。。这个性能上不去肯定是不行的后期
3. 分布式, 负载均衡, 权限控制这些功能慢慢再加上去, 初步考虑封装好,放在消费者调用API之前这一层, 避免供应者容器二次连接通信,参考了一下dubbo,好像他们也是这样做的,当然人家都是java,持久运行,不用考虑这个
4. 需要快速写个注册中心的展示界面,有没有大神参与一起写写啊?公司人手不够啊
因为这个也不属于目前工作的业务范围,只是先试水做出来,所以写了一些代码放到 github上,其实也是接触SOA不多, 架构上应该有很多考虑不周,欠妥的地方,慢慢完善吧~~ :)
代码地址: https://github.com/r00tjimmy/ttsoa, ttsoa, 代码会不断更新,有兴趣的请提点反馈意见,谢谢~