异构(兼容dubbo)SOA系统架构(.net)优化升级

前面一片文章已经提高我们公司的异构(兼容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、服务端的代码非常简单

    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("callDemo");
                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、多种容错算法和多种负载均衡算法可供配置

等我完成手头其他更紧急的工作,将准备启动下一版本的开发

时间: 2024-11-05 06:03:35

异构(兼容dubbo)SOA系统架构(.net)优化升级的相关文章

SOA系统架构

一.SOA原理与应用 1.SOA原理 SOA(Service-oriented architecture,面向服务架构). SOA的价值在于跨越了不同应用系统.不同技术的整合,这种整合改变现有的商业模型. SOA是在计算环境下设计.开发.应用.管理分散的逻辑(服务)单元的一种规范.这个定义决定了SOA的广泛性.SOA要求开发者从服务集成的角度来设计应用软件,即使这么做的利益不会马上显现.SOA要求开发者超越应用软件来思考,并考虑复用现有的服务,或者检查如何让服务被重复利用.SOA鼓励使用可替代的

魅族秒杀致流量暴增,系统架构如何优化?

一.为什么难 秒杀系统难做的原因:库存只有一份,所有人会在集中的时间读和写这些数据. 例如魅族手机每周一的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如12306抢票,亦与秒杀类似,瞬时流量更甚. 二.常见架构 流量到了亿级别,常见站点架构如上: 1)浏览器端,最上层,会执行到一些JS代码 2)站点层,这一层会访问后端数据,拼html页面返回给浏览器 3)服务层,向上游屏蔽底层数据细节 4)数据层,最终的库存是存在这里的,mysql是一个典型 三.优化方向 1)将请求尽量拦

dubbo框架----探索-大型系统架构设计(图解)

对于高并发系统的架构要求: 1. 负载均衡 2.高并发 3.高可用 4.面向服务架构 (Dubbo框架使用) 5.分布式缓存 (redis分布式缓存) 6.分布式全文检索 (solr分分布式全文检索) 7.分布式数据库集群 (mycat 集群mysql数据库) dubbo  简介 系统架构 redis 集群 solr 集群 mysql 集群

002 --品优购的系统架构

品优购采用的是SOA系统架构,为什么会采用这种架构风格?当然有他自己的好处! 1.1SOA的概念? 面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来.接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台.操作系统和编程语言.这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互.    SOA系统架构得优点: 1:简单系统的开发:由于SOA具有组合性,可以利用现有的SOA资源,根据同样的开放标准,不

Entity Framework 数据并发访问错误原因分析与系统架构优化

本文主要记录近两天针对项目发生的数据访问问题的分析研究过程与系统架构优化,我喜欢说通俗的白话,高手轻拍 1. 发现问题 系统新模块上线后,使用频率较高,故在实际使用和后期的问题重现测试中,产生了一下系列的数据访问错误 错误是比较常见的错误 2. 分析问题 系统的架构为前端.业务层与数据层三层架构,采用Entity Framework 3.5作为数据处理技术,采用shared context per request模式,参照的是codeplex上的一个示例.示例地址(此文通俗易懂,代码结构也很清晰

Linux服务器企业集群架构部署搭建(二)----linux系统基础脚本优化、内核优化

第四章 linux系统内核优化相关 参考文章: linux内核TCP相关参数解释 http://os.chinaunix.net/a2008/0918/985/000000985483.shtml linux内核参数优化 http://blog.chinaunix.net/uid-29081804-id-3830203.html linux内核调整和内核参数详解 http://blog.csdn.net/cnbird2008/article/details/4419354 linux运维老男孩培

【58沈剑架构系列】秒杀系统架构优化思路

一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的数据,一个人读多个人的数据: 3)秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据. 例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如:12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存.读写冲突,锁非常严重,这是秒杀业务难的地方.那我们怎么优化秒杀业务的架构呢? 二

秒杀系统架构优化思路

[总结] 上文应该描述的非常清楚了,没什么总结了,对于秒杀系统,再次重复下我个人经验的两个架构优化思路: (1)尽量将请求拦截在系统上游(越上游越好): (2)读多写少的常用多使用缓存(缓存抗读压力): 浏览器和APP:做限速 站点层:按照uid做限速,做页面缓存 服务层:按照业务做写请求队列控制流量,做数据缓存 数据层:闲庭信步 并且:结合业务做优化 一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的

高性能网站性能优化与系统架构(ZT)

转载请保留出处:俊麟 Michael’s blog (http://space.itpub.net/7311285/viewspace-97) 我在CERNET做过拨号接入平台的搭建,而后在Yahoo&3721从事过搜索引擎前端开发,又在MOP处理过大型社区猫扑大杂烩的架构升级等工作,同时自己接触和开发过不少大中型网站的模块,因此在大型网站应对高负载和并发的解决方案上有一些积累和经验,可以和大家一起探讨一下. 一个小型的网站,比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达