异构(兼容dubbo)SOA系统架构(.net)优化升级
2016-11-18 18:14
225 查看
前面一片文章已经提到我司的异构(兼容dubbo)SOA系统架构,解决了不少技术痛点,也还算比较完善,也顺利推广开来。
但作为项目的开发者,自己产品的问题心里是清楚的,离自己满意还是有不小的距离。
在推广的同时,我紧张的进入了下一个版本的开发,让它更加完善。
原来的版本号是1.0,现在版本升级为1.1且已经开发完成并发布(内部),本次升级主要内容如下:
1、修正了一些bug
2、简化了SOA使用
强化IOC的作用,解耦对象关联性
使用公司内部Nuget管理SOA及相关依赖
简化方法调用及方法参数(尽量只保留必须的参数)
3、性能提升、cpu和线程资源占用适当下降
高效异步线程,减少应用程序启动时间
高效对象复用节省内存和cpu消耗
4、稳定性提升
增加故障转移(出错的节点将会在负载均衡列表中移除,避免服务异常zookeeper未及时通知导致的大量报错)
优化zookeeper连接状态检测和维护(连接中断及时重新连接)
增加服务端优雅下线机制
5、强化配置
增加了很多可选配置满足业务和性能需要
可以对单个服务单独个性化配置
6、强化日志
对SOA内部几乎每个组件和每个服务都可以配置单独的日志
可以开启所有日志也可以选择性的开启部分日志
以上开发测试工作耗了三个多月,当然这里面包含一些基础建设工作,其意义不只是SOA受益,比如内部Nuget、日志、IOC容器优化,
一、1.1版本使用控制台做服务端的例子
1、使用Nuget安装Fang.SOA
所有引用(含ZooKeeper和Thrift)一键搞定
2、其实要安装的东西还是挺多的,如果没有Nuget就会让人崩溃
3、不要被太多组件(dll)吓到,大部分dll很小的,都是独立的功能
注:大家可以看到以上截图是9月初的,开发完成时间实际是11月中旬;也就是说9月初设计完成且基本目标已经完成并调试通过,其后又经历漫长的两个多月不断得修改bug和优化;一路过来痛并快乐着,看着离自己的目标一步步越来越近。
4、服务端的代码非常简单
哈哈,简单吧。
除了简单还有什么?是不是也非常的流畅啊
你没看错,以上区区几个行代码就完成了SOA服务的发布工作
注:如果要在同一个应用程序中注册(发布)多个服务依次注册即可
5、对比1.0版本少的东西
5.1 ZKInit方法没有了
这是一个重大变化,原来是要先把zooKeeper连接上才可以"发布"服务的
现在没有这个必须前提了,zooKeeper连接异步化了,需要zooKeeper的时候从IOC容器中获取,如果容器没有,再异步连接zooKeeper并保存到IOC容器中,以后需要的时候随时取。
5.2 增加了container(IOC容器)
这也是一个重大变化,现在SOA配置是依赖容器的,实际所有的参数都是从容器获取,程序初始化的时候给需要的每个参数在容器里面注入了默认值,如果需要配置覆盖默认值即可
上面的SOALoadSettings就是容器扩展方法,用于把appSettings中SOA相关节点的数据加载容器中
其实几乎SOA各大组件、运行需要对象、对象缓存服用很多都是用该容器实现的
5.3 1.0版本中ZKConsumer一哥的位置被无情的抛弃了
1.0版本中ZKConsumer几乎是.net SOA直接交互的唯一一个类
后来随着SOA系统完善,我发现ZKConsumer担不起一哥这个角色就抛弃了它,启用与SOA"毫无关系"的IContainer(容器接口)
这会是以后的趋势,我们"不再需要牢记"每个系统个性化的业务名词(类),我们使用IContainer通用对象的扩展方法来定义简单Api
我们使用一个系统的方法就变成了引用该系统的Nuget包(dll),引用该系统的命名空间,然后在IContainer下找该系统的Api(扩展方法)来用即可
启动一个系统就变成了给该系统配置容器,可以通过文件配置也可以通过代码配置
5.4 有人可能说还少一堆配置,这全都默认值可不行
那些配置可以在appSettings中配置,每个服务还可以单独配置,提供了一堆IContainer的扩展方法来配置
把1.0例子中的配置全加上后的代码如下:
有人说,你这代码更多了,是对1.0版的退化吗?
其一、并不是每个服务都有那么多个性化的配置,提供必须参数的简单api提高使用体验
其二、配置多元化了,代码配置不再是不二选择,必须写的代码更少了
二、日志配置
1、日志配置是本次升级的主要内容之一
一个容器扩展方法SOALog就可以搞所有SOA的日志记录,增加日志后的代码如下:
2、开启日志默认效果如下:
这是我本地15号至今一直在跑的本地测试服务,日志文件稍微有点大,但是日志性能还是比较可靠的,全日志下几乎不影响高并发的执行耗时
对于每个服务都有单独的日志
默认按天分文件,当然也可以不记录文件,输出到控制台或者数据库等,这样的话就要配置了,配置一个日志工厂到容器中,超出本文范畴不再展开
3、能不能只开启部分日志
当然可以,提供了一堆日志配置方法(容器扩展方法),SOALog只是他们的总司令而已
呵呵,这么多款日志配置,总有一款适合你。
三、1.1版客户端的例子
1、直接上代码(nuget安装引用同服务端)
注:1.1客户端还是满满的容器扩展方法,简洁的Api,和服务端一样可以使用容器配置服务的个性化的参数(这里就不展开了)
2、执行效果如下:
我本地跑着4个服务,按轮询提供服务
五、畅想将来版本
前面基本把本次升级的内容展示出来,算是我比较满意的版本,其性能和稳定性已经不输java的dubbox。
但是我还有继续优化的冲动,也整理几点尚未实现但是我很期待的功能
1、完全容器配置支持
就是类似dubbo一样在spring容器中配置一下就可以了
2、DI支持
把服务工厂Aop封装为服务接口,直接DI服务接口对象到需要的地方,执行方法最开始获取一个真实对象,执行方法结束回收
3、多种容错算法和多种负载均衡算法可供配置
等我完成手头其他更紧急的工作,将准备启动下一版本的开发
但作为项目的开发者,自己产品的问题心里是清楚的,离自己满意还是有不小的距离。
在推广的同时,我紧张的进入了下一个版本的开发,让它更加完善。
原来的版本号是1.0,现在版本升级为1.1且已经开发完成并发布(内部),本次升级主要内容如下:
1、修正了一些bug
2、简化了SOA使用
强化IOC的作用,解耦对象关联性
使用公司内部Nuget管理SOA及相关依赖
简化方法调用及方法参数(尽量只保留必须的参数)
3、性能提升、cpu和线程资源占用适当下降
高效异步线程,减少应用程序启动时间
高效对象复用节省内存和cpu消耗
4、稳定性提升
增加故障转移(出错的节点将会在负载均衡列表中移除,避免服务异常zookeeper未及时通知导致的大量报错)
优化zookeeper连接状态检测和维护(连接中断及时重新连接)
增加服务端优雅下线机制
5、强化配置
增加了很多可选配置满足业务和性能需要
可以对单个服务单独个性化配置
6、强化日志
对SOA内部几乎每个组件和每个服务都可以配置单独的日志
可以开启所有日志也可以选择性的开启部分日志
以上开发测试工作耗了三个多月,当然这里面包含一些基础建设工作,其意义不只是SOA受益,比如内部Nuget、日志、IOC容器优化,
一、1.1版本使用控制台做服务端的例子
1、使用Nuget安装Fang.SOA
所有引用(含ZooKeeper和Thrift)一键搞定
2、其实要安装的东西还是挺多的,如果没有Nuget就会让人崩溃
3、不要被太多组件(dll)吓到,大部分dll很小的,都是独立的功能
注:大家可以看到以上截图是9月初的,开发完成时间实际是11月中旬;也就是说9月初设计完成且基本目标已经完成并调试通过,其后又经历漫长的两个多月不断得修改bug和优化;一路过来痛并快乐着,看着离自己的目标一步步越来越近。
4、服务端的代码非常简单
class Program { static IContainer _container; static void Main(string[] args) { IContainer container = _container = new SimpleContainer() .SOALoadSettings();//加载appSettings配置 CreateHelloWorld(container);//HelloWorld服务 container.SOAStart();//启动所有服务 Console.ReadLine(); } /// <summary> /// HelloWorld服务 /// </summary> /// <param name="container"></param> private static void CreateHelloWorld(IContainer container) { string serviceName = "com.fang.HelloWorld$Iface";//服务名 var service = new HelloWorldImp();//服务实现逻辑 container.SOAProvider<HelloWorldService.Iface>(serviceName, service);//注册服务 } }
哈哈,简单吧。
除了简单还有什么?是不是也非常的流畅啊
你没看错,以上区区几个行代码就完成了SOA服务的发布工作
注:如果要在同一个应用程序中注册(发布)多个服务依次注册即可
5、对比1.0版本少的东西
5.1 ZKInit方法没有了
这是一个重大变化,原来是要先把zooKeeper连接上才可以"发布"服务的
现在没有这个必须前提了,zooKeeper连接异步化了,需要zooKeeper的时候从IOC容器中获取,如果容器没有,再异步连接zooKeeper并保存到IOC容器中,以后需要的时候随时取。
5.2 增加了container(IOC容器)
这也是一个重大变化,现在SOA配置是依赖容器的,实际所有的参数都是从容器获取,程序初始化的时候给需要的每个参数在容器里面注入了默认值,如果需要配置覆盖默认值即可
上面的SOALoadSettings就是容器扩展方法,用于把appSettings中SOA相关节点的数据加载容器中
其实几乎SOA各大组件、运行需要对象、对象缓存服用很多都是用该容器实现的
5.3 1.0版本中ZKConsumer一哥的位置被无情的抛弃了
1.0版本中ZKConsumer几乎是.net SOA直接交互的唯一一个类
后来随着SOA系统完善,我发现ZKConsumer担不起一哥这个角色就抛弃了它,启用与SOA"毫无关系"的IContainer(容器接口)
这会是以后的趋势,我们"不再需要牢记"每个系统个性化的业务名词(类),我们使用IContainer通用对象的扩展方法来定义简单Api
我们使用一个系统的方法就变成了引用该系统的Nuget包(dll),引用该系统的命名空间,然后在IContainer下找该系统的Api(扩展方法)来用即可
启动一个系统就变成了给该系统配置容器,可以通过文件配置也可以通过代码配置
5.4 有人可能说还少一堆配置,这全都默认值可不行
那些配置可以在appSettings中配置,每个服务还可以单独配置,提供了一堆IContainer的扩展方法来配置
把1.0例子中的配置全加上后的代码如下:
private static void CreateHelloWorld(IContainer container) { string serviceName = "com.fang.HelloWorld$Iface";//服务名 var service = new HelloWorldImp();//服务实现逻辑 string serviceIp = "192.168.109.166";//发布服务使用ip int servicePort = 5000;//发布服务使用端口 string group = "kg";//应用程序分组 string serviceVersion = "1.0.0";//服务版本 int serviceTimeOut = 5000; //服务超时阈值(单位Millisecond) int alertElapsed = 3000; //服务执行耗时监控报警阈值(单位Millisecond) int alertFailure = 10; //服务每分钟出错次数监控报警阈值 container.SOAServiceHost(serviceIp, servicePort, serviceName) .SOAServiceGroup(group, serviceName) .SOAServiceVersion(serviceVersion, serviceName) .SOAServiceTimeout(serviceTimeOut, serviceName) .SOAAlertelapsed(alertElapsed, serviceName) .SOAAlertfailure(alertFailure, serviceName); container.SOAProvider<HelloWorldService.Iface>(serviceName, service);//注册服务 }
有人说,你这代码更多了,是对1.0版的退化吗?
其一、并不是每个服务都有那么多个性化的配置,提供必须参数的简单api提高使用体验
其二、配置多元化了,代码配置不再是不二选择,必须写的代码更少了
二、日志配置
1、日志配置是本次升级的主要内容之一
一个容器扩展方法SOALog就可以搞所有SOA的日志记录,增加日志后的代码如下:
static void Main(string[] args) { IContainer container = _container = new SimpleContainer() .SOALoadSettings()//加载appSettings配置 .SOALog();//开启所有日志 CreateHelloWorld(container);//HelloWorld服务 container.SOAStart();//启动所有服务 Console.ReadLine(); }
2、开启日志默认效果如下:
这是我本地15号至今一直在跑的本地测试服务,日志文件稍微有点大,但是日志性能还是比较可靠的,全日志下几乎不影响高并发的执行耗时
对于每个服务都有单独的日志
默认按天分文件,当然也可以不记录文件,输出到控制台或者数据库等,这样的话就要配置了,配置一个日志工厂到容器中,超出本文范畴不再展开
3、能不能只开启部分日志
当然可以,提供了一堆日志配置方法(容器扩展方法),SOALog只是他们的总司令而已
呵呵,这么多款日志配置,总有一款适合你。
三、1.1版客户端的例子
1、直接上代码(nuget安装引用同服务端)
public class HelloWorldTest { static IContainer _container; public static void Test() { IContainer container = _container = new SimpleContainer() .SOALoadSettings()//加载appSettings配置 .SOALog(); Subcribe(container);//订阅com.fang.HelloWorld string str = null; do { str = Console.ReadLine(); if (string.Equals(str, "Exit", StringComparison.CurrentCultureIgnoreCase)) return; Console.WriteLine("callService"); CallService();//调用服务 } while (true); } private static void Subcribe(IContainer container) { string serviceName = "com.fang.HelloWorld$Iface";//服务名 string serviceGroup = "kg";//服务分组 container.SOAConsumer<HelloWorldService.Iface>(serviceName, serviceGroup, zooKeeper); } private static void CallService() { if (_container == null) return; string results = null; using (var resource = _container.SOAService<HelloWorldService.Iface>()) { if (resource == null) return results; HelloWorldService.Iface service = resource.Service; if (service == null) { Console.WriteLine("service is null"); return results; } else { var socket = resource.Socket; Console.WriteLine(string.Concat(socket.Host, ":", socket.Port.ToString(), "为您服务")); } try { results = service.sayHello("Word"); } catch (Exception ex) { var socket = resource.Socket; if (socket != null) Console.WriteLine(string.Concat(socket.Host, ":", socket.Port.ToString(), "出错")); Console.WriteLine(ex.Message); } } } }
注:1.1客户端还是满满的容器扩展方法,简洁的Api,和服务端一样可以使用容器配置服务的个性化的参数(这里就不展开了)
2、执行效果如下:
CallService 192.168.109.166:3459为您服务 Hello word CallService 192.168.109.166:3458为您服务 Hello word CallService 192.168.109.166:3457为您服务 Hello word CallService 192.168.109.166:3456为您服务 Hello word CallService 192.168.109.166:3459为您服务 Hello word CallService 192.168.109.166:3458为您服务 Hello word CallService 192.168.109.166:3457为您服务 Hello word
我本地跑着4个服务,按轮询提供服务
五、畅想将来版本
前面基本把本次升级的内容展示出来,算是我比较满意的版本,其性能和稳定性已经不输java的dubbox。
但是我还有继续优化的冲动,也整理几点尚未实现但是我很期待的功能
1、完全容器配置支持
就是类似dubbo一样在spring容器中配置一下就可以了
2、DI支持
把服务工厂Aop封装为服务接口,直接DI服务接口对象到需要的地方,执行方法最开始获取一个真实对象,执行方法结束回收
3、多种容错算法和多种负载均衡算法可供配置
等我完成手头其他更紧急的工作,将准备启动下一版本的开发
相关文章推荐
- 异构SOA系统架构之Asp.net实现(兼容dubbo)
- 基于AgileEAS.NET SOA 平台SAAS架构技术的开源分销ERP系统-SmartERP.NET下载配置说明
- SOA 架构中的ESB是更好的应用于异构系统集成整合还是用于统一服务调用/基础服务实施
- 基于Dubbo的分布式系统架构-使用Dubbo进行规模服务化前的工程结构优化
- 从LiveJournal后台发展看 大型网站系统架构以及性能优化方法
- SOA 新业务语言 新系统架构——SOA原则
- 本周任务asp.net 1.1老系统移植升级到asp.net 2.0,又是一个浩大的工程啊?
- SOA架构下分销管理系统的实现
- (转宝贝记).net 框架设计 签名系统三层架构
- .net下分层架构系统的开发技术规范(1)
- 从LiveJournal后台发展看 大型网站系统架构以及性能优化方法
- IFS应用系统-面向服务的架构(SOA)
- 基于SOA的异构系统通信解决方案
- SOA 新业务语言 新系统架构——SOA与Web Service
- SOA 新业务语言 新系统架构——SOA与Web 2.0
- SOA 新业务语言 新系统架构——参考模型和重要概念
- 从LiveJournal后台发展看 大型网站系统架构以及性能优化方法
- asp.net(c#)操作iis全功能版系统(08年3月5日正式发布升级版本)
- 一个中型OA系统的架构过程(.net)
- .net下分层架构系统的开发技术规范(1)