01 Lassen Sie uns zunächst über den historischen Ballast dieses Systems sprechen
Unsere Werbemaschine durchlief vor dieser Rekonstruktion etwa eineinhalb Jahre der Iteration. In der Anfangsphase war sie auf Suchszenarien ausgerichtet, mit einem Einzelgeschäft und klare Prozesse.
1. Die Geschäftsszenarien wurden zunehmend komplexer. Zusätzlich zur Suchmaschinenwerbung musste sie auch Informationsflussempfehlungen und ähnliche Empfehlungsszenarien unterstützen.
2. Der Werbeverkehr beginnt rasant zuzunehmen. Neben der Erfüllung der funktionalen Anforderungen muss auch die Leistung berücksichtigt werden.
Nach dem Aussortieren kann der größte Teil der Logik der gesamten Engine gemeinsam genutzt werden, daher haben wir ein Hauptgerüst definiert und die erweiterbaren Teile abstrahiert. Auf diese Weise kann jedes Szenario entsprechend den Besonderheiten seines eigenen Unternehmens bestimmte öffentliche Schnittstellen implementieren. Darüber hinaus haben wir aus Performance-Sicht die Lesbarkeit des Codes geopfert und einige Logik parallelisiert.
Mit der Geschäftsentwicklung begann das Suchszenario in eine Phase schneller Iteration einzutreten, in der immer mehr neue Strategien hinzugefügt wurden und unser Hauptrahmen zu diesem Zeitpunkt allmählich unflexibel wurde.
1 Um mit der speziellen Suchlogik kompatibel zu sein, müssen wir in anderen Szenarien verschiedene Wenn-Urteile hinzufügen, um diese Logiken zu umgehen.
2. Es gibt immer mehr Werbestrategien, insgesamt Dutzende. Wenn das Framework seine klare Struktur verliert, beginnt die Umsetzung einiger Strategien, es mangelt an hierarchischer Unterteilung und einem steckbaren abstrakten Design.
Der Wendepunkt kam Ende 2019. Aufgrund der Besonderheiten des Werbegeschäfts begann der Verkehr natürlich zu sinken. Darüber hinaus konzentrierte sich das Produktbetriebsteam auf die Arbeitsplanung für das zweite Jahr , was uns sehr geholfen hat, mit dem Wiederaufbau zu beginnen.
Wir haben die Bauzeit auf 1 Monat festgelegt und am Ende war es nur einen Tag später als erwartet online. Obwohl zwei Online-Probleme auftraten, wurden diese rechtzeitig während der Graustufenphase entdeckt und behoben, und es gab keine Offline-Probleme Unfall verursacht wurden.
02 Welche Vorbereitungen haben wir vor dem Refactoring getroffen?
Die Menge des dieses Mal überarbeiteten Codes ist sehr groß, mehr als 30.000 Zeilen, und es handelt sich um den Kernmotor des Werbesystems. Vor dem Start können wir mit folgenden Schwierigkeiten rechnen:
1. Widerstand auf der Unternehmensseite: Diese Umstrukturierung kann zwar langfristige F&E-Effizienz bringen Das Geschäftseinkommen kann nicht direkt verbessert werden, und der Entwicklungszyklus wird nicht zu kurz sein. Wie können wir Unterstützung von Kommilitonen aus der Wirtschaft erhalten?
▍Lassen Sie alle die Schmerzpunkte sehen
Wie bereits erwähnt: Mit der Geschäftsiteration ist das Hauptgerüst unserer Werbemaschine verschwommen und Dutzende Werbestrategien sind in verschiedenen Geschäftsszenarien mit chaotischen Konfigurationen verstreut.
Als Reaktion auf diese beiden Schwachstellen haben wir einen Monat im Voraus begonnen, das bestehende Geschäft zu sortieren, alte Codes zu lesen und frühere Anforderungsdokumente durchzusehen. Schließlich haben wir die Kernprozesse und Werbestrategien verschiedener Szenarien in ein A eingeteilt klare Form.
Diese Tabelle ermöglicht es Technologie und Produkten zum ersten Mal, das Gesamtbild unseres Motorteils klar zu erkennen und die Komplexität des Geschäfts und die aktuellen technischen Engpässe zu verstehen.
▍Nachdem wir die Ziele und Werte des Refactorings geklärt hatten und jedem die Schwachstellen bewusst gemacht hatten, planten wir zwei Kernziele für dieses Refactoring:
1 des Hauptrahmens: Modularisieren Sie den Hauptprozess, definieren Sie die Protokolle der oberen und unteren Schicht neu und stellen Sie sicher, dass jede Ebene auch intern abstrahiert werden muss und eine gute Skalierbarkeit aufweist.
2. Flexible und konfigurierbare Strategien: Werbestrategien werden nach Geschäftsabsichten klassifiziert und abstrahiert, die Ausführungsbedingungen der Strategien sind dynamisch konfigurierbar und die Strategien können nach Belieben ein- und ausgeschaltet werden.
Darüber hinaus haben wir die erwarteten Vorteile verfeinert, die nach Erreichen dieser beiden Kernziele erzielt werden können:
1. Technische Vorteile: Die Codestruktur ist klarer, einfacher zu verstehen und zu warten; die Skalierbarkeit wird verbessert und die Effizienz der Engine-Entwicklung wird weiter verbessert.
2. Geschäftsvorteile: Strategien können eine detailliertere Konfiguration und Erweiterung ermöglichen und sind geschäftsfreundlicher. Eine verbesserte F&E-Effizienz kann die Geschäftsiteration weiter beschleunigen.
Nachdem der Wert des Wiederaufbaus für alle synchronisiert wurde, steigert er die Begeisterung aller weiter und gibt allen eine stärkere Motivation zur Teilnahme. ▍Kontrolle des Gesamtrhythmus
Die Kontrolle des Gesamtrhythmus ist ebenfalls ein sehr wichtiger Teil, damit jeder eine Zeitvorstellung für diese Angelegenheit haben kann.
Zunächst haben wir die Bauzeit auf 1 Monat festgelegt, einerseits auf die maximal akzeptable Durchlaufzeit, andererseits auf eine schnelle Lösung aus technischer Sicht Das Frühlingsfest rückt näher und wir müssen uns beeilen, bevor das Unternehmen geschlossen wird. Gehen Sie online, bevor Sie online gehen, und reservieren Sie einen Puffer von 1-2 Wochen, um unerwartete Situationen zu vermeiden.
Darüber hinaus haben wir mit der Unternehmensseite eine Vereinbarung getroffen: Während der Umbauzeit werden nicht dringende Anforderungen für den Motorteil nicht akzeptiert. Dadurch können parallele Entwicklungs- und Codekonflikte minimiert werden und das Team kann sich stärker konzentrieren. 03 Welche Erfahrungen können Sie während des Implementierungsprozesses teilen?
Dieses Refactoring verlief so reibungslos, dass ich 4 wertvolle Erfahrungen mit Ihnen teilen kann. 1. Hochwertige technische Designlösungen
Dies ist auf die täglichen Anforderungen zurückzuführen. Wir entwerfen technische Lösungen für Projekte mit einem Entwicklungszyklus von mehr als 3 Tagen. Diese Rekonstruktion ist sicherlich keine Ausnahme.
Die Gesamtarchitektur des Frameworks, das Protokolldesign zwischen Modulen und das Skalierbarkeitsdesign der Strategie stehen im Mittelpunkt dieser technischen Lösung, die das Team nicht weniger als dreimal besprach.
Nachdem der große Plan fertiggestellt war, verfeinerte das Team die öffentlichen Teile wie Datenbank, Schnittstellenfelder, Cache-Struktur, vergrabene Protokollpunkte usw. weiter. Da es sich um eine kollaborative Entwicklung mit mehreren Personen handelt, stimmte das Team zu, Dokumente als zu verwenden Die Kommunikationsschnittstelle und Dokumente bleiben immer mit Ihrem Code synchron.
Unter solch hohen Anforderungen erstellte das Team ein technisches Lösungsdokument mit mehr als 5.000 Wörtern und insgesamt 36 Seiten, das eine gute Grundlage für die allgemeine Qualitätssicherung legte. 2. Refactoring des Framework-Codes
Dieser PR ist sehr wichtig und der wichtigste Schritt von der Implementierung unserer technischen Lösung bis zum Code. Wir haben die rekonstruierte Paketstruktur, die Modulaufteilung, die API-Definition zwischen den einzelnen Schichten und die Abstraktion verschiedener Werbestrategien geklärt und dabei zunächst die Implementierungsdetails ignoriert.
Auf diese Weise wird im Grunde der Hauptcode gebildet, der unser ideales Framework klar darstellen kann. Anschließend organisierten wir mehrere zentrale Codeüberprüfungen und bildeten schließlich eine einheitliche Meinung.
Mit diesem Schritt kann sehr gut vermieden werden, dass man sich zu früh mit den Implementierungsdetails beschäftigt, was zu einer unzureichenden Aufmerksamkeit für das Hauptframework führt und eine spätere Überarbeitung tatsächlich die Effizienz beeinträchtigt.
3. Häufige Kommunikation und gepaarter Codeüberprüfungsmechanismus
Nach Eintritt in die detaillierte Implementierungsphase ist ein sehr wichtiger Punkt: Verständnis der vorhandenen Logik. Der Motorcode wurde anderthalb Jahre lang von vielen Menschen in der Geschichte entwickelt, aber dieses Mal beteiligten sich nur drei Studenten an der Rekonstruktion.
Wenn wir während des gesamten Prozesses auf unklare Codelogik stießen, haben wir wiederholt kommuniziert und überprüft und keine subjektiven Vermutungen angestellt. Diese Vorsicht ist tatsächlich sehr wichtig.
Darüber hinaus haben wir für die Codeüberprüfung Studenten zugewiesen, die mit diesem Geschäft vertraut sind und für jedes Modul verantwortlich sind. Sie werden paarweise gebildet und der Mechanismus ist flexibel.
4. Effektiver Testplan
Refactoring wurde nicht durchgeführt, zuerst testen. Dieses Prinzip wird im Buch „Refactoring“ hervorgehoben und steht auch im Mittelpunkt unserer Diskussion dieser technischen Lösung. Ich werde es hier im Detail hervorheben.
Zunächst haben wir in der Anfangsphase eine Vereinbarung getroffen: keinen alten Code anzufassen und ein komplett neues Paket für den Wiederaufbau zu erstellen. Dadurch ist es einfach, die Ergebnisse vor und nach der Rekonstruktion zu vergleichen und gleichzeitig Online-Graustufenexperimente durchzuführen.
In Bezug auf den Testplan lohnt es sich, aus den folgenden 4 Punkten zu lernen:
1. Durch dieses Refactoring werden keine funktionalen Anpassungen vorgenommen, also das Verhalten des Äußeren Wenn sich die API ändert, ist diese End-to-End-Testmethode die wichtigste Methode für F&E- und QS-Tests.
2. Rauchtest: QA-Studenten stellen Rauchfälle zur Verfügung und F&E-Studenten führen den Rauchtest durch. Vor dem F&E-Test müssen alle Rauchfälle bestanden werden. Das ist in den meisten Internetunternehmen nicht üblich, bei großen Projekten aber absolut effektiv.
3. Dual-Prozess-Überprüfung der Sandbox-Umgebung: Wie bereits erwähnt, bleibt der Code vor und nach unserer Rekonstruktion erhalten, sodass die Eingabeparameter der Online-Umgebung über Skripte als Fälle erfasst werden können und dann die API-Rückgaben zurückgegeben werden Auf automatisierte Weise werden die Felder einzeln verglichen.
4. Graustufenexperiment in der Online-Umgebung: Graustufen sind für die Rekonstruktion sehr wichtig. Wir verwenden die vorhandene ABTest-Plattform, um den Graustufenverkehr schrittweise von 5 % über 10 % auf 30 % und schließlich auf 100 % freizugeben Es wurde ein sehr vorsichtiges Tempo der Volumenexpansion festgelegt und anschließend durch Protokolle und die Überwachung von Geschäftsindikatoren überprüft.
Am Ende geschrieben
Überprüfung des gesamten Wiederaufbauprozesses, zusammengefasst in den folgenden 7 Schlüsselpunkten:
1. Nutzen Sie die Gelegenheit zur Umstrukturierung 2. Frühzeitiges Sortieren ist sehr wichtig, finden Sie zuerst die Ziele und Werte, um alle zu begeistern ist nicht für den Langzeitbetrieb geeignet, es ist nicht geeignet. Parallel zum Geschäft sind hochwertige technische Lösungen erforderlich Seien Sie sorgfältig und verantwortlich für jede Codezeile. Der wichtigste Faktor sind natürlich die Menschen. Bei der Umgestaltung von Großprojekten wird die Zusammenarbeitsfähigkeit des Teams extrem auf die Probe gestellt .
Das obige ist der detaillierte Inhalt vonHardcore-Sachen: eine Reise zur Rekonstruktion von mehr als 30.000 Codezeilen in einem Kernsystem. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!