Autor | Su Huai
Editar | Tianguang
Este artigo é falar sobre arquitetura (ID: archtime) o planejamento Re: microarquitetura tópicos terceiros artigo 0 serviço a partir de hoje falamos de desenvolvimento API e gestão no ambiente de rede.
EDITORIAL
artigos anteriores têm quando se trata de serviço de micro-comunicação, Martin também mencionou mecanismo de comunicação Mr. Folwer "Cada serviço é executado em seu processo separado, o inter-serviços e usos serviço leve em sua definição de micro serviços em colaborar uns com os outros (geralmente baseados em REST API protocolo HTTP). "
Então, especificamente como ele conduziu a comunicação leve entre os vários micro-serviços? Este artigo vai servir para falar sobre o desenvolvimento aspectos API micro e governança.
Primeiro necessidade de explicar o título de "API dentro do ambiente de rede" refere-se à API para fornecer serviços de rede em outro micro chamada. Seus correspondentes "utilizadores da Internet abertas para chamadas de API," o seu método de desenvolvimento muito mesmo, mas o método de governação não era o mesmo. Por exemplo, aberto a utilizadores da Internet precisa adicionar autorização chamadas de API, autenticação, limitação de corrente e simultaneidade, estatísticas, faturamento, etc. funções no gateway API.
Este artigo é compartilhar o desenvolvimento e gestão API dentro do ambiente de rede.
Os dois primeiros artigos links:
desenvolvimento API
desenvolvimento API, a primeira consideração é o tipo de acordo com, ou é HTTP RPC API?
Em primeiro lugar, introduzir dois tipos de API:
HTTP API
HTTP API refere-se a um simples protocolo API com base em HTTP, um exemplo específico é o controlador de MVC mola, por exemplo:
"Http://127.0.0.1/helloworld/myapi.do".
RPC
RPC é um Remote Procedure Call, nome remoto Procedure Call chinesa, no local da chamada API, baseada principalmente refere-se à remota chama o método de comunicação Socket (claro, também podemos usar o protocolo HTTP para implementar chamadas RPC, por exemplo gRPC). Json-RPC e XMLRPC refere-se ao uso json ou XML maneira como comandos de transferência de dados e formato de texto.
Então, de volta para apenas essa pergunta, no final você quer usar HTTP API ou o RPC-lo? Queremos comparar a API HTTP e RPC, principalmente porque todos nós sabemos que a simples HTTP e RPC melhor desempenho baseado no Socket.
Isso é algo que emaranhada por um longo tempo, até mais tarde, gostaria de ver duas coisas, a decisão final de usar HTTP API na maioria dos cenários.
HTTP suficiente desempenho API para suportar a maioria dos projetos
Geralmente (em conformidade com a informação), a sequência de tempo de contagem, o rendimento do protocolo RPC desempenho de HTTP é duas vezes (sem pró-teste), por exemplo Protobuf, economia, Kyro, Dubbo semelhantes.
Lá, novamente o mais alto desempenho de Thrift. relatório de teste de desempenho específico pode referir-se a "RPC quadro básico teste de comparação de desempenho."
Nossa equipe após a sua própria pilha de tecnologia, custo, estabilidade, facilidade de uso, facilidade de manutenção, cenários de negócios em conta, entre outros fatores, que enfrentamos na maioria das cenas, a diferença de desempenho entre HTTP e RPC não são o principal problema.
Juntamente com HTTP resultados dos testes de desempenho são mostrados na figura superior e inferior como prova, estamos plenamente HTTP métodos API pode ser usado para desenvolver micro-serviços API.
Além disso, quando a empresa desenvolveu até certo ponto, se o desempenho de determinadas funções empresariais pressão aumenta, podemos transformar uma pequena escala utilizando RPC. Esta é também em linha com uma decisão ágil pensamento.
Abaixo está um helloworld explicação 10.000 páginas resultados dos testes de solicitação contínua, tempo total de 1.504 segundos, o pedido média leva 0,15 ms.
ambiente de teste: Tomcat7 nativa (sem otimização) rodando em uma máquina virtual local,
O seguinte é uma página helloworld resultados do teste solicitado 100.000 vezes para 100 o número de concorrentes, consumindo uma média de 11.9 milissegundos por pedido.
ambiente de teste: Tomcat7 nativa (sem otimização) rodando em uma máquina virtual local,
Portanto, de acordo com os resultados do teste acima, HTTP desempenho maneira API completamente suficiente para suportar a grande maioria do desenvolvimento API micro-serviços. Vamos RPC-estilo 2-11 podem surgir para aqueles que o tráfego em grandes empresas de Internet jogar.
cena API RESTful para o API aberta
Este é outro problema esgotante. Com relação à API HTTP, API RESTful é baseada em HTTP API adiciona alguns conceitos muito obscuras abstratas, como recurso (recurso), a expressão (representação), a transição de estado (State Transfer), uma interface unificada (Uniform Interface) .......
Depois de um torturado repetidas vezes, como "login / logout que RESTful método?", "Como conseguir a granel apagar?", "RESTful exatamente como definir o recurso?", Mais e eu sinto que este é um metafísico o problema, muito abstrato.
Nós não deve agradar à tecnologia moderna, o pensamento racional com base em suas próprias circunstâncias de pessoal técnico precisa adicionar. Então, RESTful é bom, mas não o nosso prato equipe.
Além disso, mesmo se a equipe algumas pessoas podem entender e corretamente prática, é difícil ou impossível para a equipe de tal forma para praticar corretamente.
Então, depois de uma luta que escolhemos HTTP maneira API, como desenvolver original, agora ou como desenvolver, concentrado principalmente no monitoramento e gerenciamento API acima.
Aqui eu recomendo uma olhada nesta discussão sobre sabemos quase "desenvolvimento WEB, bom uso JSON-RPC, ou um bom API RESTful? "Deus fala de várias grandes são muito bons.
https://www.zhihu.com/question/28570307
gerenciamento API
documentação da API
API o que significa que há alguém para chamá-lo, um monte de problemas se o chamador ao chamar a API, pode nem mesmo chamar corretamente, então o custo de comunicação e cooperação entre o grau de equipe interna e a equipe será fortemente afetada.
Estamos através do documento para se comunicar, o início do projeto melhor, mas ao longo do tempo, atualizar o documento torna-se menos oportuna (esta é realmente uma auto-justificação para dizer, o fato é que na maioria dos casos os documentos não são atualizados ), quando a API muda, não é fácil de descobrir quais módulos para chamar esta API.
Portanto, é preciso primeiro resolver o problema do documento não é actualizado. Embora possamos forçar todos para atualizar o gerenciamento de processos de documento, a propósito, mas para os desenvolvedores, é claramente insuficiente científica ou humana, porque uma API mudança, será modificado em dois lugares, um código de API, em segundo lugar, a documentação da API, os programadores a pensar que você tem que constantemente alternar entre código e documentação, a eficiência será inevitavelmente afetada.
Nós queria, você poderia simplesmente precisa mudar no mesmo lugar, se você pode fazer, a documentação API atualizada não é tão problemas, uma coisa boa para as pessoas a ter.
Através de pesquisa, optamos por utilizar Swagger para escrever um documento, de acordo com as normas de Swagger, adicione um pouco de anotação descritiva na API nele.
Através da anotação acima, ele irá gerar automaticamente a seguinte documentação API online.
O chamador pode preencher os parâmetros na interface de documento API e clique no botão "Experimente!" Para tentar chamar esta API. Assim, sob nenhum provedor de suporte circunstâncias API que pode completar a maior parte das chamadas de API, não é legal?
gestão da cadeia de chamada
API desenvolvida, e documentação da API está escrito, o próximo passo é para ser chamado. Artigos mencionado antes, até à Primavera de Nuvem de Eureka + Fita + Zuul pode facilmente chamada para a API.
Então, como controlar API chama quem, e se o errado chamada e razões erradas, como chamar o desempenho de cada elo da API, não é a existência de zumbis API ...... Estas são as perguntas sobre a governança API.
Para atingir esse objetivo, há uma maneira relativamente complicado é fazer o artigo na fita do cliente, gravá-lo antes de chamar a hora de início API, após a chamada API retorna, chamadas de API recorde demoradas, o status da chamada, se o registro está errado sobre a causa do erro.
Se você deseja rastrear a cadeia de chamada, você pode adicionar um pedido ID cadeia de chamada com antecedência, para que eles vieram e levaram todas as ligações até relacionamento chamada.
Abaixo está a nossa própria investigação e desenvolvimento dos componentes de gerenciamento de cadeia de chamada (DCTrace) várias representações:
Ligue para a relação entre o serviço de micro-view, desempenho chamada
Verifique razão para a falta de chamada
visão gráfica da relação de chamadas, muito confuso, a próxima iteração para melhorá-lo
De pé sobre a perspectiva de gerentes de tecnologia, cadeia de chamada pode ser visto a partir do fora para dentro, relacionamento impróprio entre os módulos que ; a relação entre os quais módulos do presente, o fato não é, e comparando a cadeia de chamada Swagger lista de API para encontrar a API zumbi ......
teste API
Depois de usar arquitetura de micro-service, API é a única capacidade de exportação de cada micro-serviços. Devido ao rápido desenvolvimento da indústria da Internet, o software precisa mudar para se tornar cada vez mais frequentes, iterativa atualizar a velocidade se torna mais rápido.
Para os provedores, a necessidade de assegurar que o processo de mudança e de iteração, não afeta a funcionalidade prometeu antes (incluindo precisão, estabilidade e desempenho, etc.).
Para o chamador, a mesma necessidade de garantir a sua utilização API normal, dependente, não porque o erro causado por outros módulos afetado seus negócios (incluindo precisão, estabilidade e desempenho).
Afinal, do ponto de vista organizacional, um erro de sistema é um erro, independentemente da causa é a sua própria causa ou chumbo aos prestadores de serviços, de modo que o chamador para o prestador de serviços é necessário para gerenciar o serviço.
É por isso que há alguns anos atrás test Compact método (Pacto) popular. amigos interessados podem ir e ver este método de teste.
Para caixa-branca API, é recomendado o uso de estrutura de teste REST Assured baseado em Java, com um particularmente conveniente.
https://github.com/rest-assured/rest-assured
Além disso, baseado no protocolo HTTP, padronizado JSON / mensagens XML, pode desenvolver uma ferramenta de teste pequena API (vamos chamá-lo de Kitty Hawk) para substituir RESTO-confiante. Nós também praticam ainda, mas que seria útil para sua referência.
passos básicos são:
Os prestadores de serviços para desenvolver API, e escrito corretamente documento Swagger.
A API selecionado prestador de serviços a ser testado em Kitty Hawk na interface, e preencher os parâmetros de teste. (Listas de API e os parâmetros podem ser obtidas pelo telefone API do Swagger)
Chamador para o serviço de acordo com seu entendimento, também terá seu próprio serviço útil configuração API fornecida pela Kitty Hawk.
Kitty 7 * 24 horas para o provedor de serviços eo chamador para inspecionar estas API, e enviar um alerta quando ocorre uma exceção.
Escrito na última
Assim, para o desenvolvimento de micro-serviços API, nós
O uso mais comum de tecnologia (tais como Spring MVC) desenvolveu uma API
Use REST Assegurada (e futuro Kitty) teste
Use Swagger para gerenciar a documentação da API
gestão DCTrace cadeia de chamadas Use o auto-desenvolvimento
viva hoje
tópico:
5 anos, a partir de estagiários para nível de pesquisa e desenvolvimento departamento, diretor da BAT Foster estrada
outline:
Transformação do campo da tecnologia da maneira
Como lidar com o gargalo de desenvolvimento?
De estagiário a diretor de pesquisa e desenvolvimento para atualizar a estrada
Quem diz que os jovens programadores não conseguem?
Su Huai, micro sinal Sulaohuai, Aoyagi, diretor de pesquisa e desenvolvimento em nuvem, agora está servindo a equipe Digital Aoyagi nuvem, trabalhou na Oracle, Singapore Telecom e outras empresas. Ela é especializada em tecnologia de recipiente, arquitetura micro-service, desenvolvimento ágil e gestão técnica.
texto recomendou hojeClique abaixo para ler a imagem
aceleração da Web, o acordo com antecedência!
