Quando criar mais microservices em vez de funções internas

5

Estou tentando arquitetar (detalhamento) um aplicativo que temos em meu trabalho em alguns microservices. Antes de começar a descer para a toca do coelho, eu queria perguntar: quando é uma boa idéia criar outro modelo + função ao invés de criar um microsserviço?

Criar um microsserviço envolve mais trabalho do que apenas algumas outras funções. Especialmente se isso envolver alguma duplicação de dados. Eu vi essa pergunta / resposta que foi realmente ótima: Como você lida com conceitos compartilhados em uma arquitetura de microsserviço?

Isso me ajudou muito a começar a esboçar minha macroapplication. Mas ainda não consigo resolver isso; por exemplo, eu tenho vários recursos que possuem 1) tipos diferentes e 2) atributos diferentes para os tipos. Esse é um relacionamento muitos-para-muitos.

Exemplo

# ResourceType_Attribute table
| ID | type_id | attribute_id |
|----|---------|--------------|
|  1 |       1 |            1 |
|  2 |       2 |            1 |
|  3 |       2 |            2 |

E teríamos uma tabela para tipo e atributo no mesmo microserviço. Mas agora eu quero criar uma calculadora de custos do recurso (uma função) ou um serviço de faturamento (outro microsserviço). É possível criar um novo microsserviço sem um grande fardo?

Se eu criar uma calculadora de custos, precisarei criar uma nova tabela no gerenciador de recursos:

# Cost calculator table
| ID | type_id | attribute_id | unit_cost |
|----|---------|--------------|-----------|
|  1 |       1 |            1 |         10|
|  2 |       2 |            1 |          1|
|  3 |       2 |            2 |          4|

Supostamente agora que temos um recurso de type_id 2 que tem um valor de 10 para attribute_id 1 e um valor de 10 para attribute_id 2. Isso faz o cálculo do custo: 10 * $ 10 + 10 * $ 4 = $ 140.

Ter uma função modelo + no gerenciador de recursos para lidar com esse problema facilita a realização de alterações na coluna unit_cost. Desde que eu sei o que está em attribute_id e em type_id.

Por outro lado, se eu tiver um novo microsserviço para esta tabela, não saberei quais preços estou atualizando sem consultar as tabelas de atributos e tipos. Eu só terei seus ids e tenho que ir ao outro banco de dados para verificar o que está acontecendo onde.

Eu entendo o conceito disso? Se não, por favor me ajude a esclarecer este problema. Muito obrigado!

    
por tupan 19.11.2018 / 22:23
fonte

2 respostas

4

Limites de microsserviços são tipicamente limites de domínio.

Portanto, se você tem dois métodos, ambos conceitualmente acessam a mesma estrutura de dados de back-end, mas cada um deles serve um domínio de negócios diferente, então eles se enquadram em diferentes microsserviços.

Por exemplo, você pode ter algum método de acompanhamento de presença e outro método usado para calcular a folha de pagamento com base na participação. O primeiro é usado principalmente para fins de auditoria, para garantir que rastreamos quem estava no cargo quando, enquanto o outro é usado para calcular as horas de trabalho de um funcionário.

Apesar do fato de que ambos acessariam os mesmos dados (time in e time out), um ficaria sob microsserviço de auditoria, enquanto o outro ficaria sob microsserviço de folha de pagamento.

Referência: Microsserviço de construção, projetando sistemas refinados por Sam Newman

    
por 19.11.2018 / 22:50
fonte
4

Os microsserviços fazem parte da solução para problemas de escalabilidade. Pense em microsserviços como funcionários que podem processar diferentes tarefas. Portanto, se você tiver mais cálculos de orçamento para executar, basta adicionar mais funcionários e fornecer manuais predefinidos para executar tarefas específicas.

A implementação de microsserviços tem um custo e vantagens. A decisão depende de você, considerando essa taxa de benefício / custo. Naturalmente, os benefícios não são aplicáveis a todos os casos. Você não resolverá seus problemas emocionais delegando ações a mais funcionários.

O custo é que a implementação é complexa: você precisa ter certeza de que os funcionários podem trabalhar de forma independente e coordenada. Então, você precisará desenvolver mais manuais e colocar mais funcionários para realizar essa tarefa. Mas se você tiver sucesso, poderá realizar mais vendas, por exemplo. Basicamente, você está adicionando mais filas a um processo de vendas: mais mesas aceitando comandos de clientes, mais mesas aceitando caixas de empacotadores, mais mesas aceitando caixas e entregando-as.

No seu caso específico, não vejo claramente como a arquitetura de microsserviços ajudaria. Os problemas que você aborda são programáticos, não arquitetônicos. Se você quiser criar um "gerenciador de recursos", como você o chama, pense no manual (ou manuais) para escrever para cada funcionário adicional para executar tal tarefa. Se você puder criar um procedimento que possa manipular o processo sem afetar a integridade do banco de dados e sem dependências entre funcionários usando o mesmo manual, tudo bem. Por exemplo, você pode adicionar um (micro) serviço a novos funcionários que executam cálculos atômicos (cada um calcula um item) e outro de funcionários que apenas soma valores. Eu pessoalmente não faria isso, já que os funcionários da segunda linha criarão dependências nos resultados da primeira linha (por exemplo, uma soma não pode ser realizada até receber todos os cálculos, portanto, se um funcionário da calculadora tiver um problema, um grupo de pessoas estar esperando em torno de um balcão de sumô até que ele chegue, e se ele não o fizer, todos esses processos pendentes exigirão manipulação).

Como disse, acho que você não precisa de microservices para resolver esse problema, mas não pode ter certeza, já que não sei exatamente os problemas aqui. Se eu estivesse aprendendo, eu pessoalmente codificaria ambos para experimentar as diferenças.

    
por 22.11.2018 / 05:25
fonte