[JAVA] Wie Dubbo-basierte Microservices die Architektur von Versicherern verändern werden

Xiaobin von China Life berichtet, wie Dubbo seine Architektur geändert hat und erwägt, auf ** Alibaba Cloud ** zu migrieren.

• Dieser Blog ist eine Übersetzung aus der englischen Version. Sie können das Original von [hier] überprüfen (https://www.alibabacloud.com/blog/how-dubbo-based-microservices-are-used-in-insurance-companies_595512). Einige maschinelle Übersetzungen werden verwendet. Wir würden uns freuen, wenn Sie auf Übersetzungsfehler hinweisen könnten. * *

Über Dubbo

Im Jahr 2013 hat die chinesische Lebensversicherungsgesellschaft [RPC Framework](https://searchapparchitecture.techtarget.com/definition/Remote-Procedure-Call-RPC?spm=a2c65.11461447.0.0.552b21f2f6yvpZ] die gesamte Geschäftsdatenbank transformiert. ) War auf der Suche nach. Zu dieser Zeit gab es nur wenige ausgereifte Produkte auf dem Markt, wie Spring Cloud und [Dubbo](https: // dubbo). Es gab viele Produkte auf dem Markt, wie z. B. .apache.org / de-de /? Spm = a2c65.11461447.0.0.552b21f2f6yvpZ). Was wir suchten, war ein Framework, das in einer Produktionsumgebung weit verbreitet war. Dubbo wurde in Taobao schon lange eingeführt und das Geschäftsmodell von Alibaba war mit unserem vergleichbar. Zum Beispiel erfordert unser Geschäftsmodell, dass wir auf Anfragen aus mehreren Regionen in Übersee mit jeweils eigenen Geschäftsanforderungen reagieren.

Aus diesem Grund haben wir 2013 auch mit Dubo begonnen. Wir haben 2016 in Hongkong und Macau und im Mai 2019 in Indonesien Geschäftssysteme gestartet. Da wir Dubbo verwenden, planen wir in Zukunft, unser Geschäftssystem in ganz Südostasien, einschließlich Singapur, schnell zu erweitern.

Dubbo hat mir in Bezug auf effiziente Bereitstellung und Kosteneinsparungen sehr geholfen. In diesem Artikel werde ich die Pre-Dubbo-Architektur diskutieren, die vielen traditionellen Versicherern gemeinsam ist, und dann darüber sprechen, wie Dubbo verwendet wurde und wie sich die Architektur geändert hat.

Was Versicherungsunternehmen in der Vergangenheit getan haben

Wenn es um Serverhardware geht, verwenden wir normalerweise IBM oder HP [Minicomputer](https: // www), wie es viele andere traditionelle Versicherungsgeschäftssysteme verwenden. Es war .techopedia.com / definition / 4615 / minicomputer). Zu diesem Zeitpunkt waren nur diese beiden Systeme verfügbar, auf denen beide ein UNIX-basiertes Betriebssystem ausführten.

In Bezug auf die Geschäftsarchitektur wurde Client / Server-Architektur bisher hauptsächlich in der Softwareentwicklung verwendet. Unter einer solchen Architektur ist eine leistungsstarke Middleware namens Tuxedo eine verteilte Transaktion. Es wurde für das Management verwendet und bot eine hervorragende Konsistenz und eine hohe Währungsperformance. Warum müssen wir Tuxedo überhaupt ersetzen? Der erste Grund sind hohe Preise, der zweite Grund ist der Mangel an zugehörigem O & M-Personal, der dritte Grund ist die Geschäftsintegration sowie die Leistung und Planung in verteilten und plattformübergreifenden Szenarien. Ist schlimmer zu werden. Der vierte Grund ist, dass Tuxedo für monolithische Anwendungen ausgelegt ist. Infolgedessen besteht keine Absicht der Aufteilung.

So transformieren Sie das Kerngeschäftssystem

Diese Abbildung zeigt die Vorteile von Mikrodiensten gegenüber monolithischen Anwendungen. Dubbo dient zur Interaktion zwischen verschiedenen Komponenten, die den konvexen und konkaven Teilen eines Lego-Spielzeugs ähnelt. Es implementiert Kommunikationsmanagement und Service Governance. Unterstützt von diesem Design durchbricht es die große traditionelle Kernarchitektur.

OneLife ist unsere Business Support-Plattform. Wie der Name schon sagt, kann eine Plattform alle Versicherungsvorgänge abwickeln, ein internes Ökosystem bilden und verschiedene Bereiche wie Bilder, neue Dienste, Speicherung und Schadensregulierung unterstützen. Wir bieten auch Engines wie Workflow, Produkt-Engine, Underwriting-Engine und Message-Engine. Diese Geschäftsfunktionen sind für jede Versicherungsgesellschaft von wesentlicher Bedeutung.

Von Dubbo entwickelte Plattform für die Verarbeitung von Versicherungsgeschäften

Mit der Unterstützung von Dubbo haben wir eine neue Plattform für die Verarbeitung von Versicherungsgeschäften aufgebaut, um die Verarbeitung von "Six Multi" -Versicherungsgeschäften zu realisieren. Six Multi steht für die Idee, mehrere Geschäftssysteme, Produktlinien, zu befolgende Vorschriften, Engines und Währungssprachen zu haben. Um beispielsweise eine Versicherungspolice zu erstellen, müssen Sie entscheiden, ob Sie diese auf Englisch, Chinesisch oder Indonesisch erstellen möchten. Zu diesem Zweck ist es natürlich erforderlich, mit jedem Geschäftsbereich zusammenzuarbeiten, und es ist auch erforderlich, eine geeignete Verarbeitungsplattform zu entwerfen und zu entwickeln.

Bildung eines verteilten OneLife-Systems

Wie in der Figur gezeigt, kann eine geschlossene Schleife mit den folgenden vier Teilen gebildet werden. Dubbo-basierter Microservice-Aufruf Jenkins -basierte kontinuierliche Integration, Rancher a2c65.11461447.0.0.552b21f2f6yvpZ) -basierte Cloud-Bereitstellungsanwendung, punktbasierte Kettenüberwachung. Wir haben mit Alibaba Cloud über die indonesische Version der Cloud-Bereitstellung diskutiert. In Zukunft könnten indonesische Systeme die ersten sein, die auf Alibaba Cloud umsteigen. In Bezug auf die punktgenaue Kettenüberwachung ist die angezeigte Topologie sehr einfach zu verstehen, aber basierend auf dieser Topologie können wir einige Probleme wie zerbrochene Formationen und fehlgeschlagene Aufrufe erkennen. .. In diesem Jahr konnten wir mithilfe der Pinpoint-Kettenüberwachung über 100 Fehler feststellen. Die Kombination aus Pinpoint Chain Monitoring und Dubbo ist hervorragend.

Wie man Dubo in Hong Kong und Macau vertreibt

Dubbo verfügt über mehr als 150 Server, mehr als 210 Anwendungen, mehr als 2.100 Verbraucher und mehr als 1.300 Anbieter, die in Hongkong und Macau verteilt sind. Versicherer, insbesondere ihre Geschäftssysteme, haben nicht viele häufige Transaktionen. Die meisten Hochfrequenztransaktionen finden am Frontend statt. Geschäftssysteme befinden sich nicht immer in einem Hochfrequenzzustand, aber es ist dennoch wichtig, dass alle Geschäftssysteme stabil und genau ausgegeben werden. Dies ist einer der Gründe, warum ich mich für Dubo entschieden habe.

Funktionsweise von Dubbo China Life Insurance (Overseas) Co., Ltd.

Etwa 70% unseres Geschäfts verwenden die ursprüngliche Dubbo-Version (speziell 2.4.9). Zuvor habe ich einige Code-Korrekturen basierend auf Dubbo vorgenommen, z. B. die Kompensation für verteilte Transaktionen. Danach stellte ich fest, dass ich kein Upgrade durchführen konnte, da ich eine größere Codekorrektur vorgenommen hatte. Dann fragen Sie sich vielleicht, welche Art von Framework für die verbleibenden 30% des Geschäfts verwendet wird. Ich versuche nur die neueste Version auf einem Peripheriegerät. Darüber hinaus wurde diese Version auf die Branchenarchitektur angewendet, nachdem sie sich als praktisch und machbar erwiesen hat. Derzeit erhält Dubbo von China Life Insurance (Overseas) Co., Ltd. mehr als 21 Millionen Anrufe pro Tag, und seit der Einführung von Dubbo ist kein Systemabsturz aufgetreten.

Dubbo-Struktur

Wir werden die Konfiguration hier teilen. Zwei Probleme werden hervorgehoben. Das erste Problem ist der Wiederholungsmechanismus. Das Problem dabei ist, dass wenn der Dienst unterbrochen wird, er manuell über die Steuerungsplattform interveniert werden kann oder wenn der Dienst wichtig ist, er durch Wiederholen der Transaktion kompensiert werden kann. Die zweite Herausforderung besteht darin, dass die Verwendung des ZooKeeper Registration Centers seine Nachteile aufgrund des enormen Spitzenverbrauchs des Netzwerks hat. Das Datenkonzept für Dubbo Version 2.7 ist vielversprechend. In Zukunft möchte ich versuchen, Dubbo Version 2.7 oder höher zu verwenden, um zu sehen, ob ich die Mängel von ZooKeeper überwinden oder ZooKeeper optimieren kann.

Dubbo Microservice-Anwendungsszenario

Die obige Abbildung zeigt eine Dubbo-Microservice-Anwendung. Die Anwendung startet auf der Seite mit den Onlinediensten und wechselt zur neuen Dienstkomponente. Danach wird der Workflow gestartet und das Akzeptanzergebnis abgefragt. Basierend auf dem Zeichnungsergebnis wird das Prämienberechnungsergebnis automatisch abgefragt und an das Frontend zurückgegeben. Niedrige Kosten sind eine Voraussetzung für den Einsatz unternehmenskritischer Systeme und Vertriebssysteme in Indonesien. Sie müssen auch die Geschäftsbereiche trennen. Dies beinhaltet das Basisentwicklungsmodell. Was ist das Basisentwicklungsmodell?

Wenn Ihr Unternehmen auf mehrere Regionen verteilt ist, benötigen Sie für jede Region eine eindeutige Version. Wenn die veröffentlichten Basisversionen identisch sind, können Sie die Effizienz Ihres Unternehmens verbessern. Zum Beispiel hat der Hauptsitz grundlegende Dienstleistungen, aber Indonesien hat seine eigenen Vorschriften. Wenn in Hongkong in Zukunft eine solche Nachfrage besteht, werden wir nach Bestehen einer bestimmten Prüfung der Basisversion die Basisversion zurücksetzen und für jede Region eine andere Basisversion veröffentlichen. Kurz gesagt, in komplexen Situationen unterstützt die Basisversion die hierarchische Trennung verschiedener Geschäftslogiken, das hierarchische Code-Management sowie die hierarchische und regionale Service-Governance.

Vorschlag

Erstens verbessert es die visuelle Kontrolle.

Zweitens wird ein Service-Grid bereitgestellt und verpackt, um mehr Funktionen in Microservice-Systemen bereitzustellen, einschließlich Netzwerkanrufen, Verkehrsbeschränkungen, Leitungsblockierungen und Überwachung zwischen Diensten.

Drittens unterstützt es mehrere Sprachen. Dubbo bietet derzeit PHP-, Node.js-, Python- und Go-Clients an, plant jedoch, in Zukunft weitere zu unterstützen.

Viertens empfehlen wir Dubbo nicht, um das verteilte Transaktionsmanagement zu unterstützen. Als ich Dubbo zum ersten Mal verwendete, entschied ich, dass ich verteilte Transaktionen unterstützen musste. Daher habe ich den Code basierend auf Dubbo geändert. Die Anwendung war reibungslos und der Code konnte die Transaktionskonsistenz zwischen den Plattformen sicherstellen. Wenn der Dienst jedoch fehlschlug, brachen alle von ihm gesendeten Transaktionen zusammen, was ein schwerwiegendes Risiko für die Datenbank darstellte.

Daher halte ich es für wünschenswert, dass Dubbo die Unterstützung für den Nachrichtenmechanismus erhöht und das Geschäft entwickelt, während verteilte Transaktionen kompensiert werden. Das Obige sind einige Ideen und Vorschläge, die durch praktische Anwendung entstanden sind.

Häufig gestellte Fragen

Frage 1: Wird monolithische Anwendungen schrittweise oder in großen Mengen durch Microservice-Komponenten ersetzt? Und wie viel Personal und Ressourcen benötigen Sie, um den Austauschprozess abzuschließen?

A1: Zunächst wird die vorhandene Struktur modularisiert und die Module sind unabhängig voneinander. Für die wichtigsten Datenstrukturen müssen Sie die Geschäftslogik trennen. Legen Sie danach die Datenbank-Shards und Berechtigungen fest und ersetzen Sie die Module schrittweise. Vor der Entwicklung sollte der gesamte Austauschprozess gut geplant sein. Als wir das erste Modul starteten, waren nur fünf Personen anwesend, aber alle waren technisch versiert und mit ihren jeweiligen Geschäftsfeldern vertraut. Die Unterstützung des Managements hatte oberste Priorität.

F2: Wie kann ich Dateninkonsistenzen erkennen, wenn die verteilte Transaktionssteuerung in meinem System nicht verfügbar ist? Und wie kann dieses Problem gelöst werden?

A2: Die punktgenaue Kettenüberwachung ermöglicht es dem O & M-Personal, Probleme schnell zu erkennen, Fehler zu beheben und dann manuelle Eingriffe durchzuführen. Der MQ-Mechanismus wird für den Schlüsseldienst verwendet. Dieser Mechanismus verbraucht jedoch viel Zeit und Personal. Wir glauben, dass eine umfassende verteilte Transaktionskontrolle vermieden werden sollte.

F3: Wenn die Datenmenge im Unternehmen groß ist, wie sollte die Oracle-Datenbank ersetzt werden, wenn Daten vom alten auf das neue System migriert werden? Können Sie diese Frage beantworten?

A3: Auf Datenbankebene muss bestätigt werden, dass die Tabellenstruktur und die Daten der Oracle-Datenbank mit denen anderer Datenbanken übereinstimmen. Zum Vergleich können Tools wie ETL verwendet werden. Auf Anwendungsebene können Sie zwei Schritte ausführen. Der erste Schritt ist die Automatisierung des Prozesses. Mit dem selbstkompilierenden Tool können Sie die SQL-Anweisungen Ihrer Anwendung in beiden Datenbanken ausführen und die Fehler rechtzeitig beheben. Nach der dritten Ausführung können fast alle SQL-Anweisungen normal ausgeführt werden. Der nächste Schritt besteht darin, wichtige Algorithmen und Schnittstellen zu überprüfen und die von der neuen Schnittstelle ausgegebenen Daten mit den Geschäftsdaten zu vergleichen.

• Alibaba Cloud ist der Cloud-Infrastrukturbetreiber Nr. 1 (2019 Gartner) im asiatisch-pazifischen Raum mit zwei Rechenzentren in Japan und mehr als 60 Verfügbarkeitszonen weltweit. Klicken Sie hier, um weitere Informationen zu Alibaba Cloud zu erhalten. Offizielle Seite von Alibaba Cloud Japan *