Spider RPC-Entwicklungshandbuch

Protokoll und Kompatibilität

Spider wird in der Java-Sprache entwickelt, verwendet Spring als IoC-Container und übernimmt das TCP/IP-Protokoll. Auf dieser Grundlage wird es gezielt und fokussiert auf die Eigenschaften von entwickelt Das SaaS-Systemmodell ist flexibler und effizienter, um die Anforderungen von mandantenfähigen Systemen, hoher Verfügbarkeit und verteilter Bereitstellung zu erfüllen.

Bei Verwendung von JSON als Serialisierungsmechanismus könnten nachfolgende Versionen die Unterstützung von Protobuf in Betracht ziehen (Java/C/C# werden von Klassenbibliotheken unterstützt).

Um Leistung und Stabilität zu maximieren, wird Spider auf Basis von Sun JDK1.8 kompiliert und sollte die Verwendung der veralteten Funktion vermeiden.

Um sich möglichst gut an verschiedene Umgebungen und Internetanwendungen anpassen zu können, sollte Spider zumindest unter dem Tomcat/JBoss-Anwendungsserver lauffähig sein.

Bereitstellungsmodus

Spider kann jederzeit entweder im zentralisierten Verwaltungsmodus oder im unabhängigen Verwaltungsmodus ausgeführt werden.

Zentralisierter Verwaltungsmodus: Der zentralisierte Modus erfordert, dass das Servicecenter aktiviert ist. Bei groß angelegten Bereitstellungen mit Dutzenden laufender Knoten erfordert das Hinzufügen oder Reduzieren eines Knotens/Aufteilen eines Dienstes normalerweise eine große Anzahl von Konfigurationsdateien. Normalerweise muss jeder Knoten, der sich vor dem neuen Knoten befindet, die entsprechenden Routing- und Zuordnungsserverparameter ändern. Mit dem zentralisierten Verwaltungsmodell müssen Sie sich nur beim Servicecenter anmelden, um relevante Konfigurationen zu ändern, und Knotenänderungen werden automatisch an die entsprechenden Upstream-Knoten weitergeleitet. Im zentralisierten Verwaltungsmodus können Sie den Gesundheitsstatus aller Knoten auf der gesamten Plattform, TPS, Reaktionszeit usw. jedes Dienstes im Servicecenter anzeigen.

Unabhängiger Verwaltungsmodus: Für den unabhängigen Verwaltungsmodus ist keine Aktivierung des Servicecenters erforderlich. Wenn die Anzahl der Knoten gering ist, beispielsweise wenn die gesamte Plattform zehn Knoten nicht überschreitet, ist es normalerweise einfacher, einen unabhängigen Modus als einen zentralisierten Verwaltungsmodus zu übernehmen. Bei der Ausführung im unabhängigen Verwaltungsmodus können Sie den Betriebsstatus des aktuellen Knotens über die von Spider bereitgestellte Restful-API anzeigen.

Service-Identifizierung

Spider unterstützt zwei Arten von Service-Veröffentlichungsanmerkungen.

Spider definiert zwei benutzerdefinierte Anmerkungen zur Identifizierung von Spider-Diensten.

Service Module

@Retention(RetentionPolicy.RUNTIME)

public @interface ServiceModule {

String subSystemId() default "0";

}

@ServiceModule ist nur eine Klassenanmerkung. Die Schnittstelle mit dieser Annotation wird als Spider-Service-Schnittstellenklasse betrachtet. Die Definition in dieser Schnittstelle ist eine notwendige Voraussetzung für die Identifizierung als Spider-Service.

Service-Schnittstelle

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
public @interface Service {
    String serviceId(); // 服务编号，8位ASCII字符，其中00000000-00000099为spider内部保留，00000100-00000199为服务中心保留
    String desc(); //服务描述
    int timeout() default 0; //超时时间，单位毫秒
    boolean needLog() default false; //设置是否记录日志
    int broadcast() default 0;  //设置该请求是否广播，0：不广播；1：广播但无需相应；2：广播并响应
}

@Service ist eine Methodenanmerkung, die drei Attribute enthält, die zum Festlegen der Spider-Service-Nummer, der Spider-Service-Beschreibung und des Spider-Service-Timeouts verwendet werden. Das Zeitlimit ist optional und der Standardwert ist der in Spider.xml festgelegte Wert. Wenn er nicht in Spider.xml definiert ist, beträgt der Standardwert 300 Sekunden.

Nur mit @Service annotierte Methoden, die in der mit @ServiceModule annotierten Schnittstelle definiert sind, werden als Spider-Dienste identifiziert. Nach korrekter Veröffentlichung kann diese Schnittstelle zur Bereitstellung von Diensten oder Proxy-Aufrufen an Remote-Dienste verwendet werden.

Für Dienste mit Broadcast=2 muss der Rückgabewert in das Datenattribut von com.ld.net.spider.pojo.BroadcastResult eingeschlossen werden. Weitere Informationen finden Sie in der Javadoc-Beschreibung dieser Klasse.

Umgebungsvariablen

Spider verfügt über einige Umgebungsvariablen zur Steuerung verwandter Optionen. Derzeit gibt es die folgenden einstellbaren Umgebungsvariablen, wie unten gezeigt:

l SPIDER_LOG, default/tmp/spider/stat/${nodeName}

l SPIDER_HOME, default/usr/local/spider/${nodeName}

l SPIDER_CONFIG, geben Sie Spider.xml an Startdatei, Standardklassenpfad: Spider.xml, siehe Abschnitt zur Konfigurationsdatei.

Konfigurationsdatei

Siehe Abschnitt zur Konfigurationsdatei.

Dienstleistungsverlag und Agentur

Dienstveröffentlichung: Das serviceExportPackage-Element unter dem Spider.localService-Plugin definiert den Paketpfad des Spider-Dienstes, der automatisch veröffentlicht wird, wenn der Spider-Knoten als Server dient, getrennt durch oder. Solange der Server den entsprechenden Pfad für diesen Parameter festlegt, kann der Java-Client den entsprechenden Dienst, der vom Remote-Server-Paket bereitgestellt wird, direkt über die @Autowired-Abhängigkeitsinjektion aufrufen, solange er den entsprechenden Pfad für den Parameter serviceProxyPackage festlegt.

Dienst-Proxy: Für Java-Clients bietet Spider eine automatische Proxy-Funktion. Entwickler können den Spider-Dienst auf dem Remote-Server aufrufen, genau wie der Aufruf des lokalen Spring-Dienstes Das serviceExportPackage-Element definiert den Paketpfad des Spider-Dienstes, der automatisch weitergeleitet werden muss, getrennt durch; Für Nicht-Java-Clients wie C#- oder C-Clients müssen Entwickler den entsprechenden SDK-Client aufrufen.

Der veröffentlichte Dienst und der Dienst des Agenten dürfen sich nicht überschneiden. Wenn ein Dienst lokal verarbeitet und von Spider-Agenten an Downstream-Server weitergeleitet werden muss, konfigurieren Sie ihn in der Release-Liste. Derzeit können diese Dienste nicht per Benutzerprogrammierung aus der Ferne aufgerufen werden. Normalerweise werden diese Dienste für spezielle Zwecke genutzt und als Broadcast bezeichnet.

PS: Technisch gesehen können sie aufgerufen werden, solange die Methodensignatur und die Dienstnummer desselben Dienstes auf dem Client und dem Server identisch sind (dh der Methodenname hat nichts damit zu tun). ), aber dies wird in zukünftigen Versionen möglicherweise auch nicht empfohlen.

Es ist auch zu beachten, dass, wenn ein Spider-Knoten die Rolle des NB spielen möchte, der Veröffentlichungspfad im serviceExportPackage konfiguriert ist und auch die Implementierung eines bestimmten Dienstes als Routing-Eintrag des Dienstes enthält Wird zur lokalen Verarbeitung geparst, wird der Dienst am NB-Knoten verarbeitet und nicht weiter weitergeleitet. Dies muss beachtet werden. Daher wird für die Rolle von NB empfohlen, sie außer für Broadcast-Dienste nicht unter serviceExportPackage zu konfigurieren.

Unterstützung verschiedener Datentypen

Die aktuelle Version von Spider unterstützt grundsätzlich alle Arten von Datentypen außer Byte[], einschließlich generischer Objekte.

Anforderungen an die Definition von Serviceschnittstellen

Unter Berücksichtigung von Flexibilität, Leistung und Entwicklungseffizienz wird empfohlen, dass sowohl Serviceparameter als auch Rückgabewerte Objekte verwenden (im Grunde bestehende RPC-Frameworks). Verwenden Sie diesen Modus, z. B. gRPC, ICE, und die Parameter erben die SpiderBizHead-Klasse (die verwandte Informationen enthält, z. B. das Festlegen des dynamischen Routings). Wie unten gezeigt:

Eingabeparameter DTO:

öffentliche Klasse ServiceReq erweitert SpiderBizHead /*Wenn Sie keine dynamische Routing-Funktion benötigen, müssen Sie SpiderBizHead nicht erben*/ {

}

Dienstsignatur:

@ServiceModule()

public interface DemoService {

                                                                                                                                 ;

}

Bedenken Sie auch die einfache Implementierung dynamischer Proxys in C und anderen verwendeten Programmiersprachen.

Informationen zu C# finden Sie in der Klassenimplementierung System.Runtime.Remoting.Proxies.RealProxy.

===================================== == =================================

Spezialisiert auf groß angelegte J2EE-SOA-Systeme mit hoher Parallelität Architekturdesign und -implementierung, kompetent in J2EE-Systemleistungsanalyse und -optimierung

Kompetent in oltp&dss Oracle- und MySQL-Datenbankdesign, Leistungsanalyse und -optimierung, HA, Subdatenbank- und Subtabellen-Anwendungsarchitekturdesign und -implementierung
Meine Open-Source-Projekte mysqlawr , dlcache, logpool, drpcp. https://git.oschina.net/zhjh256
Bereitstellen eines intelligenten Technologie-Managementsystems für medizinische Geräte, das die APS-Vorschriften jeder Provinz erfüllt