surging 微服务引擎 -协议主机的Behavior特性

1、前言

因为工作的关系,最近很少更新surging,因为surging 一直处在不温不火的状态,而自己每天利用业余时间进行完善,每天都是疲惫的状态,还要应付新手的提问,曾经一度想放弃,但是有些人劝说,surging 已经有一定的忠粉,放弃难免可惜,你可以发展收费版本,这样你也有动力进行更新,用户也有需求,付费也是情理之中,你也能更好的发展下去。就在上个月我剥离了企业版、预定版、社区版。

社区版:阉割版本,不带配置中心,文档,服务编排流程引擎,管理中心等功能,而且没有咨询服务

预定版:部分企业版本功能,有配置中心,文档,部分中间件,带咨询服务,

企业版:2天一对一培训课程,咨询服务,有配置中心,文档,服务编排流程引擎,管理中心,所有中间件,

社区版地址:https://github.com/dotnetcore/surging

2、什么是微服务

这几年微服务这个话题很火,可谓是你方唱罢我登场,什么框架都要和微服务牵扯点关系,和微服务没关系就会显得很low,对于微服务设计,没有明确的定义,所以市面大多都有自己的理解和定义,而我个人认为大部分开源都是老汤换新药,都是一个疗效没有本质的区别,最主要是骗骗领导,对外宣传公司的技术实力,而对于现实来讲,基本上真正的微服务都在一二线互联网公司,而且你会发现总公司,分公司,附属公司都要自己开发一套微服务,而这是为什么呢?因为有弊端,要开发属于自己的微服务,来满足业务的需求。那么我是怎么理解这个微服务呢?

微服务是针对业务的松耦合,是对于业务的解耦,也是粒度最小的功能业务模块,对于协议高度集成化,对于本地和远程调用的抽象化和服务治理保证了可靠性通信,技术人员只关注业务实现和拆分,而无需关注底层的业务实现。

而以上只是谈了微服务的思想,那么对于微服务就需要通过引擎扫描或者引用加载业务服务模块驱动生成服务提供者,而针对于行业解决方案,我们可以加载需要协议服务主机。那么我们下面来谈谈如何扩展协议服务主机

3、协议主机集成-behavior特性

针对于协议服务主机,我们有必要认识下behaviors,那么什么是behaviors呢?

behaviors是协议服务主机引擎特性, 每个扩展的主机都包含一个 behavior, 可以包含属性、数据、标识和方法,组件引用它时,它的属性、数据和方法会被合并到组件中,对于各自的behavior会在启动的时候进行初始化生成ServiceEntries。里面包含了类型,routepath, behaviors. 以下各个协议服务主机的behavior

BackgroundServiceBehavior:继承IServiceBehavior, 后台托管服务,可以构建后台定时任务

UdpBehavior:继承IServiceBehavior,可以集成UDP协议

WSBehavior:继承于IServiceBehavior,可以集成ws协议

GreeterBehavior: 继承于IServiceBehavior和Protos生成的GreeterBase,可以集成Grpc

MqttBehavior:继承于ServiceBase,可以集成MQTT协议

DnsBehavior:继承于IServiceBehavior,可以集成DNS

以上所有的Behavior,IServiceBehavior和ServiceBase都支持rest,rpc可靠性远程调用。

4、协议主机-Grpc

对于刚刚更新Grpc 服务主机,有些人还不会用,这里我们谈谈如何构建Grpc

业务接口

首先建立业务接口,代码如下

  [ServiceBundle("api/{Service}/{Method}")]
    public  interface IGreeterService : IServiceKey
    {
    }

proto文件

在创建proto 文件前,需要nuget安装Google.Protobuf,Grpc.Core,Grpc.Tools。

然后在业务接口模块创建的Protos/greet.proto 文件内容如下:

syntax = "proto3";

package Greet;

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user‘s name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings.
message HelloReply {
  string message = 1;
}

因为是利用Grpc.Tools工具 通过.proto文件生成C#资源文件。所以还需要编辑.csproject文件,需要把以下代码添加到.csproject文件中。

  <ItemGroup>
    <Protobuf Include="Protos\greet.proto" GrpcServices="Server" />
 </ItemGroup>

Behavior特性

针对于grpc需要再创建Behavior,并且继承通过Grpc.Tools生成的Greeter.GreeterBase和IServiceBehavior,代码如下

 public  partial class GreeterBehavior : Greeter.GreeterBase,IServiceBehavior
    {

    }

业务模块

针对于业务模块,需要继承Behavior和业务接口,代码如下

    public class GreeterService: GreeterBehavior, IGreeterService
    {
        public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
        {
            return Task.FromResult(new HelloReply
            {
                Message = "Hello " + request.Name
            });
        }
    }

配置

添加Surging.Core.Grpc引擎组件,配置GrpcPort,启用GrpcModule,配置surgingSettings.json如下

    "Ports": {
      "HttpPort": "${HttpPort}|280",
      "WSPort": "${WSPort}|96",
      "MQTTPort": "${MQTTPort}|97",
      "GrpcPort": "${GrpcPort}|95"
    }
    "Packages": [
      {
        "TypeName": "EnginePartModule",
        "Using": "${UseEngineParts}|ServiceProxyModule;DotNettyModule;NLogModule;MessagePackModule;ConsulModule;WSProtocolModule;MqttProtocolModule;EventBusRabbitMQModule;CachingModule;KestrelHttpModule;DnsProtocolModule;SwaggerModule;ApiGeteWayModule;SkywalkingModule;KestrelNLogModule;ServiceHostModule;GrpcModule"
      }
    ]

通过以上服务端配置,那么再通过创建client 进行测试

客户端

而针对于客户端,也需要nuget 安装需要Google.Protobuf,Grpc.Core,Grpc.Tools。同时创建greet.proto 文件,然后我们需要编辑.csproject文件,需要把以下代码添加到.csproject文件中。

  <ItemGroup>
    <Protobuf Include="Protos\greet.proto" GrpcServices="Client" />
  </ItemGroup>

然后封装ServiceClient调用,代码如下

using Greet;
using Grpc.Core;

namespace GrpcService1
{
    public class ServiceClient
    {
        private static ChannelBase _channel;
        private static Greeter.GreeterClient _client;

        static ServiceClient()
        {
            _channel = new Channel("127.0.0.1", 95, ChannelCredentials.Insecure);
            _client = new Greeter.GreeterClient(_channel);
        }

        public static HelloReply SayHello(string name)
        {
            return _client.SayHello(new HelloRequest
            {
                Name = name
            });
        }
    }
}

再在Main函数中调用封装好的ServiceClient,代码如下

using System;

namespace GrpcService1
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var result = ServiceClient.SayHello("fanly");

            Console.WriteLine("grpc Client Call SayHello():" + result);
            Console.WriteLine("任意键退出...");
            Console.ReadKey();
        }

    }
}

运行结果如下图所示

原文地址:https://www.cnblogs.com/fanliang11/p/11708795.html

时间: 2024-10-08 20:18:52

surging 微服务引擎 -协议主机的Behavior特性的相关文章

谈谈surging 微服务引擎 2.0的链路跟踪和其它新增功能

一.前言 surging是基于.NET CORE 服务引擎.初始版本诞生于2017年6月份,经过NCC社区二年的孵化,2.0版本将在2019年08月28日进行发布,经历二年的发展,已经全部攘括了微服务架构的技术栈,覆盖了从服务注册.服务发现.中间件.协议主机再到链路跟踪,并且制定了一套微服务的规则,形成了一套统一的规范.以下是surging的服务引擎架构图 上图Diagnostic能够实现把整个服务链路的各种信息采集到. 比如来源地址.远程地址.报错.执行时间.调用链路.协议类型以及参数全部采集

surging 微服务引擎 1.0 正式发布

surging 是一个分布式微服务引擎,提供高性能RPC远程服务调用,服务引擎支持http.TCP.WS.Mqtt协议,采用Zookeeper.Consul作为surging服务的注册中心,集成了哈希一致性,随机,轮询.压力最小优先作为负载均衡的算法,底层协议集成采用的组件是dotnetty.websocket-sharp.Kestrel.支持通过docker hub 部署服务引擎,也可以通过nuget 引用组件的方式自定义服务引擎. surging 已完成了生成环境的稳定部署,支持超过千台机器

微服务之协议概述

微服务协议 互联网协议很多,TCP IP 是基础协议,在它之上有众多应用层协议,这里关注的微服务以什么协议向外提供服务, 即以什么方式, 或者说以什么手段, 通过什么媒介来提供面向用户或者其他服务提供他们所需要的服务. 传统的单体服务对外一般提供RPC (远程方法调用)的接口, 对内的组件之间通过方法调用或者线程/进程间通信就行了. 而微服务一般所提供的服务都是节点与节点之间的远程分布式调用, 使用基于流式的TCP 连接或基于数据包的UDP 连接之上的应用层协议 协议都是分层的, OSI的七层网

(二)surging 微服务框架使用系列之surging 的准备工作consul安装

suging 的注册中心支持consul跟zookeeper.因为consul跟zookeeper的配置都差不多,所以只是consul的配置 consul下载地址:https://www.consul.io/downloads.html consul agent 命令的常用选项,如下: -data-dir 作用:指定agent储存状态的数据目录 这是所有agent都必须的 对于server尤其重要,因为他们必须持久化集群的状态 -config-dir  作用:指定service的配置文件和检查定

(五)surging 微服务框架使用系列之缓存-reids

1.服务跟客户端初始化的时候需要添加缓存配置 1 var host = new ServiceHostBuilder() 2 .RegisterServices(builder => 3 { 4 builder.AddMicroService(option => 5 { 6 option .AddCache()//缓存初始化28 });29 }).Configure(build =>47 build.AddCacheFile("cacheSettings.json",

基于docker 如何部署surging分布式微服务引擎

1.前言 转眼间surging 开源已经有1年了,经过1年的打磨,surging已从最初在window 部署的分布式微服务框架,到现在的可以在docker部署利用rancher 进行服务编排的分布式微服务引擎,再把业务进行剥离, 通过配置路径就能驱动加载业务模块,这样的细粒度设计,能更加灵活从业务中针对于对象加以细分,能更加灵活的拆分聚合服务.而这篇文章我们来谈谈基于docker 如何部署 surging源码下载 2.概述 容器,就是用来存放镜像的器皿,而镜像是构建成的一个轻量的.独立的.可执行

微服务架构(Microservices)

说在前面 好久没写博文了,心里痒痒(也许是换工作后,有点时间了吧).最近好像谈论微服务的人比较多,也开始学习一下,但是都有E文,看起来半懂不懂的. Martinfowler的<微服务>,也算是入门必读了.有人翻译过,但是只有一半.还是自己练练手吧. 微服务 "微服务架构"一词在过去几年里广泛的传播,它用于描述一种独立部署的软件应用设计方式.这种架构方式并没有非常准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上,却有着显著特征. "微服务

微服务实践(总)-原文

本系列文章为 dockone.io 首发,转载请标明出处,以示尊重!! http://dockone.io/people/hokingyang   希望读者通过本系列文章对微服务优缺点有一个比较好的理解,以及何时使用这种架构.也许微服务架构比较适合你的应用.也许你正在开发一个大型.复杂单体式应用,日常开发和部署经验非常缓慢和痛苦,而微服务看起来是远方一个极乐世界.幸运的是,有可以参考的脱离苦海的策略,本篇文章中,我将描述如何逐步将单体式应用迁移到微服务架构. 本系列七篇文章列表如下: 微服务实战

微服务&mdash;&mdash;Martin Flower【翻译】

原文地址 本文内容 微服务 微服务风格的特性 组件与服务 围绕业务功能进行组织 产品不是项目 强化终端及弱化通道 分散治理 分散数据管理 基础设施自动化 容错性设计 设计改进    微服务是未来吗 其它 微服务系统多大 微服务与SOA 多语言多选择 实践标准和强制标准 让做对事更容易 断路器circuit breaker和产品中现有的代码 同步是有害的   微服务 "微服务架构"一词在过去几年里广泛的传播,它用于描述一种独立部署的软件应用设计方式.这种架构方式并没有非常准确的定义,但是