Ola! Somos "Hosting Technologies" e lanzamos hai 5 anos — o primeiro aloxamento vds creado especificamente para desenvolvedores. Esforzámonos por facelo cómodo, como DigitalOcean, pero con soporte ruso, métodos de pago e servidores en Rusia. Pero DigitalOcean non só é fiabilidade e prezo, tamén é un servizo.
O software de ISPsystem resultou ser unha corda que nos ataba as mans no camiño cara a un servizo xenial. Hai tres anos, utilizamos a facturación de Billmanager e o panel de control do servidor VMmanager e axiña nos decatamos de que era case imposible ofrecer un bo servizo sen o noso propio panel de control.
Como o sistema ISP matou a comodidade
Erros
Non puidemos corrixir o erro nós mesmos - cada vez que tiñamos que escribir ao soporte doutra persoa e esperar. A solución a calquera problema requiría a resposta dunha empresa allea.
O soporte do sistema ISP respondeu normalmente, pero as correccións chegaron só despois duns cantos lanzamentos, e non sempre e non todos. Ás veces corrixíronse erros críticos durante varias semanas. Tivemos que tranquilizar aos clientes, pedir desculpas e esperar a que o ISPsystem solucionase o erro.
Ameaza de tempo de inactividade
As actualizacións poderían xerar tempos de inactividade imprevisibles que provocaban novos erros.
Cada actualización era unha lotería: tiven que cubrir a facturación e facer sacrificios aos deuses das actualizacións: un par de veces a actualización provocou un tempo de inactividade de 10 a 15 minutos. Os nosos administradores neste momento estaban sentados nos seus ollos: nunca soubemos canto duraría o tempo de inactividade e non puidemos prever cando o ISPsystem decidiría lanzar unha nova actualización.
Na quinta xeración, Billmanager mellorou, pero para poder acceder ás funcións necesarias, tiven que instalar unha beta, que xa se actualizaba cada semana. Se algo rompía, tiña que dar acceso a outros desenvolvedores para que puidesen arranxar algo.
Interface de panel incómoda
Todo estaba dividido en diferentes paneis e controlado desde distintos lugares. Por exemplo, os clientes pagaron a través de Billmanager e tiveron que reiniciar ou reinstalar VDS en VMManager. O noso persoal tamén tivo que cambiar entre as fiestras para axudar a un cliente, comprobar a carga do seu servidor ou ver que SO estaba a usar.
Tal interface leva tempo, tanto o noso como o dos nosos clientes. Non se trata de ningunha conveniencia, como a de DigitalOcean, ante tal situación.
Ciclos de vida curtos con actualizacións frecuentes da API
Escribimos os nosos propios complementos, por exemplo, un complemento con métodos de pago adicionais que non están en VMManager.
Nos últimos anos, VMManager tivo un ciclo de vida relativamente curto e, nas novas versións, os nomes das variables ou das funcións da API podían cambiar arbitrariamente; isto rompeu os nosos complementos. O soporte para versións antigas eliminouse rapidamente e tivo que ser actualizado.
Non se pode modificar
Máis precisamente, é posible, pero extremadamente ineficiente. As restricións de licenza non che permiten facer cambios no código fonte, só podes escribir complementos. Máximo de complementos: algúns elementos do menú, un asistente paso a paso. O sistema ISP está deseñado para a súa versatilidade, pero necesitabamos solucións especializadas.
Así que a decisión estaba madura de escribir o meu propio panel. Fixémonos obxectivos:
- Responda rapidamente a erros e erros e poida solucionalos vostede mesmo sen facer esperar ao cliente.
- Modifique libremente a interface para os fluxos de traballo e as necesidades do cliente.
- Aumenta a usabilidade cun deseño limpo e comprensible.
E comezamos o desenvolvemento.
Nova arquitectura do panel
Temos un equipo de desenvolvemento autosuficiente, polo que escribimos o panel nós mesmos.
O traballo principal foi realizado por tres enxeñeiros: o director técnico Sergey escribiu a arquitectura e escribiu o axente do servidor, Alexey fixo a facturación e o front-end foi montado polo noso front-ender Artysh.
Paso 1: axente do servidor
O axente do servidor é un servidor web Python que xestiona a biblioteca , que á súa vez goberna .
O axente xestiona todos os servizos do servidor: a creación, a detención, a eliminación de vds, a instalación de sistemas operativos, o cambio de parámetros, etc. a través da biblioteca libvirt. No momento da publicación do artigo, trátase de máis de corenta funcións diferentes, que complementamos en función da tarefa e das necesidades do cliente.
En teoría, libvirt podería controlarse directamente desde a facturación, pero isto requiría demasiado código adicional e decidimos separar estas funcións entre o axente e a facturación; a facturación simplemente fai solicitudes ao axente a través da API JSON.
O axente é o primeiro que fixemos, xa que non precisaba ningunha interface e era posible probalo directamente desde a consola do servidor.
O que nos deu o axente do servidor: apareceu unha capa que simplifica a vida de todos: a facturación non precisa enviar un montón de comandos, senón só facer unha solicitude. E o axente fará todo o que sexa necesario: por exemplo, asignará espazo no disco e RAM.
Paso 2. Facturación
Para o noso desenvolvedor Alex, este non foi o primeiro panel de control: Alex estivo no hospedaxe durante moito tempo, polo que en xeral entendeu o que necesitaba o cliente e o que necesitaba o hospedador.
Chamamos facturación entre nós un "panel de control": contén non só diñeiro e servizos, senón tamén a súa xestión, atención ao cliente e moito máis.
Para cambiar do software ISPSystem, foi necesario preservar plenamente a funcionalidade anterior para os clientes, transferir todas as accións financeiras dos usuarios da facturación antiga á nova, así como todos os servizos e conexións entre eles. Estudamos o que hai no produto actual, despois as solucións dos competidores, principalmente DO e Vultr. Analizamos as desvantaxes e vantaxes, recollemos comentarios de persoas que traballaban con produtos antigos de ISPsystem.
A nova facturación utilizou dúas pilas: PHP clásico, MySQL (e no futuro está previsto cambiar a PostgreSQL), Yii2 como marco no backend e VueJS na parte frontal. As pilas funcionan de forma independente unhas das outras, son desenvolvidas por diferentes persoas e comunícanse mediante a API JSON. Para o desenvolvemento usamos entón e agora и de JetBrains e quéroos moito (¡Ola rapaces!)
O panel está deseñado de forma modular: módulos de sistema de pago, módulo de rexistro de dominios ou, por exemplo, módulo de certificado SSL. Podes engadir facilmente unha función nova ou eliminar unha antiga. As bases para a ampliación sitúanse arquitectónicamente, incluso en sentido contrario, "cara á ferretería".
Que conseguimos: un panel de control sobre o que temos control total. Agora os erros arranxanse en horas, non en semanas, e as novas funcións impléntanse a petición dos clientes, e non a petición de ISPSystem.
Paso 3 Interface
A interface é idea do noso equipo.
En primeiro lugar, analizamos o que pasaría se fixemos un complemento sobre a API do sistema ISP sen cambiar fundamentalmente nada na interface. Resultou así e decidimos facer todo dende cero.
Criamos que o principal é facer a interface lóxica, cun deseño limpo e minimalista, e despois obteremos un fermoso panel. A localización dos elementos falouse en Megaplan e pouco a pouco irá nacendo a interface que agora ven os usuarios no panel de control.
O deseño da páxina de facturación foi o primeiro en aparecer, porque xa fixemos complementos de pago para ISPsystem.
Frontend
Decidiron facer do panel unha aplicación SPA - pouco esixente para os recursos e con carga rápida de datos. O noso front-ender Artysh decidiu escribilo en Vue, nese momento Vue acababa de aparecer. Supoñemos que o marco se desenvolvería de forma dinámica, como React, despois dun tempo a comunidade Vue crecería e aparecería un mar de bibliotecas. Apostamos por Vue e non nos arrepentimos: agora leva pouco tempo engadir novas funcións á parte frontal que xa foron programadas na parte traseira. Contarémosche máis sobre o panel frontal nun artigo separado.
Conectando o frontend ao backend
O frontend conectouse ao backend mediante notificacións push. Tiven que traballar duro e escribir o meu propio controlador, pero agora a información da páxina actualízase case ao instante.
Que pasou: A interface do panel fíxose máis sinxela. Fixémolo adaptativo e a carga rápida permíteche usalo incluso desde teléfonos móbiles nos últimos minutos antes do despegue, sen instalar unha aplicación separada para traballar co panel.
Paso 4. Esquema de probas e migración
Cando todo comezou e pasaron as primeiras probas, xurdiu a cuestión da migración. En primeiro lugar, instalamos a facturación e comezamos a probar o seu funcionamento co axente do servidor.
Despois escribimos un script sinxelo que transfire a base de datos da facturación antiga á nova.
Tiven que probar e revisar literalmente todo, xa que os datos fusionáronse nunha nova base de datos de tres antigas: Billmanager, VMmanager e IPmanager do xestor. Quizais as migracións de proba sexan o máis difícil que atopamos no proceso de desenvolvemento dun novo panel.
Despois de revisar, pechamos a factura antiga. A migración de datos final foi un momento moi preocupante, pero, grazas a Deus, completouse en poucos minutos e sen problemas notables. Houbo pequenos erros que solucionamos durante a semana. A maior parte do tempo dedicouse a probar o que pasou.
Despois enviamos cartas aos clientes coa dirección do novo panel e a facturación e fixemos unha redirección.
En resumo: ESTÁ VIVO!
Fin feliz
Dende as primeiras horas de traballo do noso software, sentimos todas as delicias da transición. O código era completamente noso e cunha arquitectura conveniente, e a interface era limpa e lóxica.
Primeira revisión despois do lanzamento do novo panel
Lanzamos o proceso de transición en decembro, na véspera do ano 2017, cando a carga era a menor, para facilitar a transición aos clientes: case ninguén traballa na véspera das vacacións.
O principal que obtivemos ao cambiar ao noso sistema (ademais da fiabilidade e comodidade xerais) é a posibilidade de engadir rapidamente funcionalidades para os clientes clave: ser a súa cara, non o seu cu.
Cal é o próximo?
Estamos crecendo, a cantidade de datos, clientes, datos de clientes crece. Tiven que engadir un servidor Memcached e dous xestores de colas con tarefas diferentes ao backend. O frontend ten caché e as súas propias filas.
Por suposto, aínda tivemos aventuras a medida que o produto se desenvolveu e facíase máis complexo, por exemplo cando engadimos HighLoad.
No seguinte artigo, contarémosche como se lanzou a tarifa Hi-CPU: sobre hardware, software, que tarefas resolvemos e que fixemos.
Fonte: www.habr.com