Pourquoi Dubbo est-il réécrit en Go ?

[[443126]]

Quelques mots d'abord

Je pense souvent à beaucoup de questions techniques "pourquoi" lorsque je marche Parfois, je réfléchis longuement à une question jusqu'à ce que je puisse me convaincre de chacune d'entre elles. point de la question. Ce n’est qu’alors qu’elle est complète. Je souhaite donc enregistrer ces réflexions et rédiger un article qui pourra être utilisé comme une nouvelle série. Vous ne pourrez peut-être pas voir le code dans ces articles, mais vous pourrez avoir un aperçu de certains problèmes qui passent facilement inaperçus, ainsi que du « pourquoi » plus profond du problème.

Aujourd'hui arrive le premier article, pourquoi Dubbo devrait-il être réécrit en Go ?

Dubbo, né à Alibaba et open source en 2011, a traversé 10 ans. En 2019, il a été réécrit en Go et open source. Deux ans plus tard, il est passé de la version originale V1.0.0 à la version V3.0.0, avec un nombre d'étoiles de 3,8K à ce jour.

Un collègue m'a demandé un jour pourquoi un "ancien" projet comme Dubbo devait être réécrit dans Go. Cela a-t-il une signification pratique ?

Permettez-moi de parler de certaines de mes opinions aujourd'hui.

Connecter le passé et le futur

Je pense que pour bien répondre à cette question, nous devons commencer par l'intention originale de Dubbo-go. Il se présente comme ceci sur la page d'accueil de github :

L'officiel. La traduction chinoise est

La mise en œuvre du langage Apache Dubbo Go construit un pont entre Java et Golang, s'interconnecte avec l'écosystème gRPC/Dubbo et permet à l'écosystème Java de profiter des dividendes technologiques de l'ère du cloud natif.

Permettez-moi de le traduire en termes simples : dans une entreprise ou un service, certaines personnes utilisent la version Java de Dubbo, et certaines personnes utilisent Go. Les deux ont besoin de communiquer, Dubbo-Go a donc été créé pour résoudre le problème de communication.

Voici donc la première question, pourquoi une entreprise utilise-t-elle Java puis Go ?

Choix du langage de programmation

Pour le choix du langage de programmation, dans les entreprises commerciales, je pense que la chose la plus importante à considérer est l'efficacité, car pour les autres points, sont secondaires. Parce que l'objectif principal d'une entreprise commerciale est de réaliser des bénéfices, quelle que soit la langue dans laquelle elle parle, tant qu'elle peut obtenir des avantages égaux au moindre coût, c'est une bonne langue.

L'efficacité comprend plusieurs aspects :

• Efficacité du développement. L'efficacité du développement est élevée, le projet peut être lancé dès que possible, occuper le marché et économiser les coûts de main-d'œuvre
• Efficacité opérationnelle. Il a une efficacité opérationnelle élevée et peut réduire les coûts de serveur

En regardant les choix de nombreuses sociétés commerciales nationales, telles qu'Alibaba, elles considèrent cela.

Alibaba a utilisé PHP à ses débuts. La principale considération dans le choix de PHP était l'efficacité du développement. Cependant, avec le développement de l'entreprise, les performances de PHP ne pouvaient plus être prises en charge et il était nécessaire de passer à un langage à haute efficacité opérationnelle. .

C/C++ vient naturellement à l'esprit lorsqu'il s'agit d'efficacité opérationnelle élevée, mais l'efficacité de développement de ces deux langages est faible. Un point d'équilibre doit être trouvé entre l'efficacité de développement et l'efficacité opérationnelle, c'est pourquoi Alibaba a choisi Java.

Quand Alibaba a officiellement répondu sur Zhihu pourquoi ils avaient choisi Java, ils ont principalement considéré les éléments suivants : performances, simplicité et facilité d'apprentissage, écologie riche et communauté active

En mettant la performance au premier plan, il est en fait facile à apprendre, riche en écologie, et actifs dans la communauté. Ils parlent tous de l'efficacité du développement. C'est précisément en raison de ces avantages que l'efficacité du développement est élevée.

Lorsqu'Alibaba a choisi Java, elle a développé un grand nombre de middleware Java et a formé un grand nombre de talents Java. Par conséquent, d'autres entreprises se sont également référées à Alibaba lors de la sélection des technologies, ce qui a amené de plus en plus d'entreprises à choisir Java.

Il en va de même pour le choix de Go. Certaines jeunes entreprises peuvent utiliser des langages de script tels que PHP et Python à un stade précoce. Après leur développement et leur croissance, elles doivent faire face au même problème qu'Alibaba : des problèmes de performances.

Go est sorti en 2012, et tout le monde avait un autre choix. Go est très performant et est très simple et facile à utiliser. De nouvelles sociétés comme ByteDance utilisent principalement Go.

Donc dans l'ensemble, il est raisonnable de choisir Java ou Go, et il est raisonnable d'exister.

Pourquoi certaines entreprises choisissent Java mais souhaitent utiliser Go ?

• Par rapport à Java, le langage Go a les caractéristiques d'un démarrage rapide, d'une vitesse de compilation rapide, d'une faible utilisation de la mémoire et d'une bonne concurrence élevée (coroutine), donc là Les entreprises Java envisageront déjà Go, mais actuellement, ces entreprises ne représentent qu'une petite proportion.
• Certaines entreprises n'ont pas de pile technologique obligatoire, donc les nouveaux départements et les nouvelles entreprises peuvent se débarrasser des contraintes et choisir le nouveau langage Go pour le développement.

Résumé

En résumé, il est raisonnable de choisir Java ou Go. Il est également raisonnable de choisir les deux au sein d'une entreprise. Bien que la proportion ne soit pas grande, il existe toujours un besoin de communication Java et Go.

La victoire de Dubbo dans le cadre RPC

Au début de l'entreprise, il s'agissait généralement d'un service monolithique. Lorsque l'échelle atteint un certain niveau et que l'application monolithique ne peut pas prendre en charge le développement commercial, elle choisit une architecture de microservices. avec le temps, un cadre RPC utile est nécessaire.

Parmi les frameworks RPC pouvant s'adapter au langage Java, Dubbo est le premier open source en Chine et a été open source en 2011.

Des concurrents similaires tels que Spring Cloud étaient open source en 2014, Motan de Weibo était open source en 2017, gRPC multilingue était open source en 2015 et Thrift était open source en 2007.

Seul Thrift est antérieur, mais Thrift n'est qu'un framework RPC, tandis que Dubbo inclut des fonctionnalités de gestion de services prêtes à l'emploi, telles que l'enregistrement et la découverte de services, l'équilibrage de charge, la tolérance aux pannes, la configuration dynamique, etc.

On peut dire que le premier framework Java RPC n'avait pas le choix.

Même à une époque où les frameworks RPC sont en pleine floraison, avec tant d'entreprises qui les utilisent et le soutien d'Alibaba, Dubbo a toujours sa place.

Résumé

Lorsqu'une entreprise choisit le langage de programmation Java et le framework Dubbo (il existe encore de nombreux choix), et souhaite ensuite essayer Go, ou qu'une nouvelle entreprise ou de nouveaux départements souhaitent essayer Go, ils sont confrontés à un problème, comment Go communique avec Dubbo de Java.

Le protocole Dubbo étant un protocole privé, le coût de sa réimplémentation dans Go est encore assez élevé. C'est ainsi que Dubbo-Go est né. De ce point de vue, Dubbo-Go a toujours une valeur considérable dans la communication entre Java et Go.

Mettez fin à la lutte avec les pools de threads

Si vous utilisez le framework Dubbo, vous avez souvent besoin d'une passerelle Dubbo. Pour plus d'informations sur la passerelle Dubbo, vous pouvez vous référer à mon article : "L'évolution des passerelles de microservices".

Dans cet article, je présente en détail le contexte, les difficultés, la sélection, la conception, l'évolution et l'expérience des pièges d'une passerelle Dubbo. J'ai passé beaucoup de temps à introduire la "lutte avec le pool de threads". précieux, mais si la passerelle Dubbo est appelée de manière synchrone, chaque requête doit occuper un thread, ce qui entraînera un échec de concurrence, et lorsque le pool de threads est plein, cela affectera les autres requêtes.

La solution est donc soit d'isoler le pool de threads, soit de passer à un appel asynchrone. Le pool de threads isolé ne résout que le problème des requêtes qui ne s'affectent pas les unes les autres, mais la concurrence n'est toujours pas améliorée. Le passage à l'appel asynchrone peut parfaitement résoudre le problème, mais le codage est trop compliqué.

La coroutine de Go peut simplement résoudre ce problème. La coroutine de Go est très légère et a une efficacité de planification plus élevée, nous pouvons donc écrire une passerelle très efficace avec un code simple.

Pour un exemple, vous pouvez ressentir intuitivement les performances de Nginx. Tout le monde connaît les performances de Nginx, mais s'il est implémenté en Java, je ne sais pas combien de machines doivent être empilées pour atteindre les performances de Nginx. Baidu utilise plutôt BFE écrit en Go pour le proxy inverse, vous pouvez voir à quel point ses performances sont exagérées.

Pour l'introduction et les principes des coroutines, vous pouvez vous référer à mon article : "Écrire Golang pendant un an, parlons des processus, des threads et des coroutines".

Résumé

Donc, sur la passerelle Dubbo, Dubbo-Go propose également une nouvelle solution. Tuya Smart dispose déjà de la passerelle Dubbo-Go pour une utilisation en ligne, et elle est open source sous le nom de Dubbo-go-pixiu.

Ouvre la voie à Dubbo Mesh

ServiceMesh est progressivement devenu l'architecture de microservices de nouvelle génération. Go est définitivement un langage vedette sur Mesh. Qu'il s'agisse de K8S, Docker et d'autres infrastructures cloud natives, ils sont tous écrits en Go. La vitesse de développement et les capacités de simultanéité élevées des coroutines en font le langage préféré pour Mesh.

Sur cette base, Dubbo's Meshization et Dubbo-Go ont également ouvert la voie. Cependant, DubboMesh en est encore à une phase à petite échelle et la solution de mise en œuvre complète n'est pas open source de ce point de vue. l'entreprise veut adopter DubboMesh Sur la voie de la transformation, Dubbo-Go peut également être l'un des points à considérer.

Résumé

Cela dit, il est temps de répondre directement pourquoi Dubbo doit être réécrit en Go. La réponse à cette question est toujours la phrase officielle : construire un pont entre Java et Golang. Quant à la raison pour laquelle nous devons « construire ce pont », veuillez vous référer à l'image ci-dessous :

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!