Arquitetura de Microservices utilizando o Microsoft SQL Service Broker – Parte 3 – Final

Olá! Antes de iniciar a última parte desta série, uma notícia boa: a White Fox se tornou parceiro Microsoft Silver em Application Development e Gold em Devices and Deployment. Além do reconhecimento, a parceria com a Microsoft é importante para dar uma visibilidade maior para a White Fox e nos permitir acesso a muito mais recursos para nosso processo de desenvolvimento. Obrigado a todos que nos ajudaram durante a certificação! Em 2016 a White Fox deve focar mais no Microsoft Azure, sempre buscando trazer o melhor da tecnologia para nossos clientes com a melhor relação custo/benefício.

No último post, mostramos a estrutura montada no SQL Service Broker para suportar nossa arquitetura de Microservices. Nesta última parte vamos mostrar as estruturas em .NET que suportam o Thin Client (cliente) e os executores. Como estamos montando uma arquitetura expansível, criamos então uma classe estática, utilizando um container Microsoft Unity, que chamamos de ServiceBus, para registrar cada cliente e executor. O código dela pode ser visto abaixo.

public static class ServiceBus {
	private static IUnityContainer iocCcontainer;
	private static bool isInitialized;

	public static void InitializeSql(string connectionStringName) {
		isInitialized = true;
		iocCcontainer = new UnityContainer();
		iocCcontainer.RegisterInstance(typeof(IStorage), new SqlStorage(connectionStringName));
	}

	public static T GetService<T>() where T: class, IService {
		if (!isInitialized) throw new ServiceBusNotInitializedException();
		return iocCcontainer.Resolve<T>();
	}

	public static void RegisterService<T>(Type type) where T : class, IService {
		if (!isInitialized) throw new ServiceBusNotInitializedException();
		iocCcontainer.RegisterType(typeof(T), type);
	}

	public static void RegisterComponent<T>(T instance) where T : class, IComponent {
		if (!isInitialized) throw new ServiceBusNotInitializedException();
		iocCcontainer.RegisterInstance(typeof(T), instance);
	}
}

As interfaces IService são os serviços de mensageria, tanto do cliente quanto do executor. As interfaces de IComponent são para classes que são responsáveis por implementar as regras de negócio do executor. Abaixo um exemplo de uso do ServiceBus, onde o ResultMessagesReceiver (que implmenta IReceiver) é o responsável por processar as mensagens de retorno recebidas e o ClienteService (que implementa IClientService) é o Thin Client.

 ServiceBus.InitializeSql("ServiceBroker");
 ServiceBus.RegisterComponent<IReceiver>(new ResultMessagesReceiver());
 ServiceBus.RegisterService<IClientService>(typeof(ClientService));

Criamos também um ServiceBase, que é usado por executores e clientes para implementar as rotinas principais de processamento de mensagens. O código está abaixo. É praticamente um loop onde as mensagens são lidas do SQL Server, dentro de uma transação, e processadas. Em caso de qualquer problema, a transação pode ser desfeita e a mensagem permanece lá. É importante notar que caso aconteçam muitos rollbacks em sequência, o SQL Server desativa a Queue (isto nos causou alguns problemas de debug!). Neste caso, a Queue deve ser reativada antes que outras mensagens possam ser lidas.

protected void ProcessMessages(int maxMessages) {
	var counter = 1;
	do {
		if (++counter > maxMessages) break;
		storage.BeginTransaction();
		try {
			var message = storage.ReadMessage(endPoint);
			if (message == null) {
				storage.Commit();
				break;
			}
			if (string.IsNullOrEmpty(message.Handle)) {
				storage.Commit();
				break;
			}
			if (initiator && message.MessageType == EndMessageType) {
				storage.EndConversation(message.Handle);
				storage.Commit();                        
				continue;
			}
			if (message.MessageType == ErrorMessageType) {
				// todo: logar o erro
				storage.EndConversation(message.Handle);
				storage.Commit();                        
				continue;
			}
			message.Date = DateTime.Now;
			if (!ProcessMessage(message)) {
				storage.Rollback();
				break;
			}
			if (!initiator) storage.EndConversation(message.Handle);
			storage.Commit();                    
		}
		catch (Exception) {
			storage.Rollback();
			throw;
		}                               
	} while (true); 
}

Abaixo está a parte relevante do código que implementa o storage do SQL Server. Optamos por simplesmente encapsular chamadas a stored procedures que ficam no banco de dados utilizado para as filas de mensagens. A seguir estão também as 3 procedures de leitura, envio e final de conversação.

 public string SendMessage(EndPointConfiguration endPoint, string data, string conversationHandle = null) {
	var parameters = new Parameters()
		.Add("initiatorService", endPoint.Initiator).Add("targetService", endPoint.Target)
		.Add("contract", endPoint.Contract).Add("messageType", endPoint.MessageType)
		.Add("data", data);
			
	if (!string.IsNullOrEmpty(conversationHandle))
		parameters.Add("handle", conversationHandle);
	StoredProcedureFacility.ExecuteScalar<string>(connectionStringName, "SendMessage", parameters)	
}

public Message ReadMessage(EndPointConfiguration endPoint) {
	var root = StoredProcedureFacility.GetXml(connectionStringName, "ReadMessage", Parameter.Create("queueName", endPoint.QueueName));
	return new Deserializer<Message>(root)
		.Property(m => m.MessageType, "mt")
		.Property(m => m.Contents, "data")
		.Property(m => m.Date, "dt")
		.Property(m => m.Handle, "ch")
		.Instance();
}

public void EndConversation(string handle) {
	StoredProcedureFacility.ExecuteNoResults(connectionStringName, "EndConversation", Parameter.Create("handle", handle));
}

Stored procedures:

CREATE PROCEDURE [dbo].[SendMessage] (
	  @initiatorService sysname,
	  @targetService varchar(255),
	  @contract varchar(255),
	  @messageType varchar(255),
      @data varchar(MAX) = NULL,
	  @handle varchar(255) = null
)
AS 
BEGIN
	if @handle is null 
	begin   declare @id uniqueidentifier   BEGIN DIALOG CONVERSATION @id
            FROM SERVICE @initiatorService
            TO SERVICE @targetService
            ON CONTRACT @contract
            WITH ENCRYPTION = OFF, LIFETIME = 7200;
		set @handle = cast(@id as varchar(255));
	  end;
	  send on conversation @handle message type @messageType (@data)                  
      select @handle;	  
END
GO

CREATE procedure [dbo].[ReadMessage](@queueName varchar(255))
as 
begin
declare @ch varchar(255)
declare @mt varchar(255)
declare @data varchar(max);
declare @dt DateTime;

set nocount on

declare @Sql nvarchar(max) = N'RECEIVE TOP(1) @h = conversation_handle, @messageTypeName = message_type_name, @Packet = message_body, @date = message_enqueue_time FROM ' + @queueName + ';'

EXECUTE sp_executesql @Sql, N'@h UNIQUEIDENTIFIER OUTPUT, @messageTypeName varchar(255) OUTPUT, @Packet VARCHAR(max) OUTPUT, @date datetime OUTPUT'
		,@h = @ch OUTPUT
        ,@messageTypeName = @mt OUTPUT
        ,@Packet = @data OUTPUT
		,@date = @dt output;

select * from (select @ch ch, @mt mt, @data [data], @dt [dt]) M for xml auto

end
GO

CREATE procedure [dbo].[EndConversation](@handle varchar(255)) as
begin
;end conversation @handle;
end

Finalmente, a seguir está o exemplo de um Thin Client, com um envio de mensagem e a rotina que faz o processamento das mensagens de retorno. Para cada tipo de ação criada, deve haver um tratamento específico. O construtor recebe, por injection (o Unity cuida disto) o storage e a classe que irá tratar as regras de negócio.

public class ClientService: ServiceBase, IClientService {	 
    private readonly IReceiver receiver;

    public ClientService(IStorage storage, IReceiver receiver)
		: base(storage, true, Configuration.Requester.Service, Configuration.Executer.Service, Configuration.Contract, 
			Configuration.Requester.Message, Configuration.Requester.Queue) {
		this.receiver = receiver;
	} 
	
    public void RequestAction1() {
      SendMessage(new MessageContent { Action = Actions.Action1});
    }

    public override bool ProcessMessage(Message message) {
       var ser = new DataContractJsonSerializer(typeof (MessageContent));        MessageContent content;        using (var ms = new MemoryStream(Encoding.UTF8.GetBytes(message.Contents))) {
		content = (MessageContent) ser.ReadObject(ms);        }        if (content == null) return true;
	try {      switch (content.Action) {
		case Actions.Action1:     return receiver.ReceiveMessage(content, message.Date);
		default:     return receiver.Error(content.Action, ErrorCodes.NotImplemented, null);
		}
	}
	catch (Exception ex) {    return receiver.Error(content.Action, ErrorCodes.Exception, ex);
    }
}

O executor não é diferente, como pode ser visto abaixo. Ele somente recebe a mensagem, faz algum tipo de ação de negócio específica e retorna os dados para o solicitante. Claro que isto é um código simplificado, já que em um código de produção é importante tratar todos os tipos de erros possíveis, evitando rollbacks da fila.

public override bool ProcessMessage(Message message) {
	var ser = new DataContractJsonSerializer(typeof(MessageContent));
	MessageContent message;
	using (var ms = new MemoryStream(Encoding.UTF8.GetBytes(message.Contents))) {
		message = (MessageContent)ser.ReadObject(ms);
	}
	if (message == null) return true;
	var returnMessage = new MessageContent {Action = message.Action};
	try {
		switch (message.Action) {
			case Action.Action1:
				returnMessage.Data = MyBusinessRulesManager.ExecuteSomething(message).ToString();
				break;
		}
	}
	catch (Exception ex) {
		returnMessage.Error = ex.Message;
	}
	SendMessage(returnMessage, message.Handle);
	return true;
}

Bom, espero ter conseguido passar uma visão geral da arquitetura de Microservices que estamos utilizando. Claro que temos muitos outros cenários que fazem com que a complexidade desta arquitetura seja bem maior. Por exemplo, temos situações onde temos mensagens geradas em horários específicos ou que só podem ser executadas em horas úteis. Isto faz com que o Executor tenha toda uma lógica para armazenar as mensagens com agendamento de execução específica em outras filas. Mas tudo isto é feito com o fundamento que mostrei nesta série. Como sempre, fiquem à vontade para entrar em contato para tirar dúvidas ou conversar mais sobre este assunto. Até a próxima!

Arquitetura de Microservices utilizando o Microsoft SQL Service Broker – Parte 2

Oi pessoal! Este post é continuação da série sobre a implementação de um barramento de microservices usando o SQL Server Service Broker (veja a primeira parte aqui).

O primeira passo é montar a infraestrutura no SQL Server. O barramento de microservices é baseado em filas, assim é necessário escolher um banco de dados para a criação das mesmas. Em tese, qualquer banco pode ser usado, mas recomendo a utilização de um banco criado especificamente para esta finalidade, para facilitar as tarefas de infra como backup, monitoração etc.

No nosso caso, criamos um banco novo, chamado, por exemplo, “MyMicroservicesBus”. Após a criação do banco, deve ser feito o comando abaixo, para que o Service Broker seja ativado no mesmo.

ALTER DATABASE MyMicroservicesBus SET ENABLE_BROKER

O próximo passo é criar as filas e contratos. Para quem não é muito familiar com os conceitos do SQL Server Broker, ver referência aqui. Recomendo também o livro “Pro Sql Server 2008 Service Broker”, bem completo. São necessárias duas filas, uma para servir de canal de comunicação da “Thin API” para o Executor (ExecuterQueue) e outra para que ele possa enviar as respostas de volta (InitiatorQueue). Para cada fila é necessário definir um contrato, que vai servir também para o versionamento das mensagens e um Service, para o roteamento de mensagens. Por último, não esquecer de dar as permissões de RECEIVE para os usuários apropriados. Um script completo é mostrado a seguir.

-- messages
create message type [http://mydomain.net/services/myservice/requestMessageV1] Validation = None
GO

create message type [http://mydomain.net/services/myservice/responseMessageV1] Validation = None
go

-- contracts
create contract [http://mydomain.net/services/myservice/contractV1]
(
	[http://mydomain.net/services/myservice/requestMessageV1] sent by initiator,
	[http://mydomain.net/services/myservice/responseMessageV1] sent by target
)
go

-- QUEUES
create queue MyServiceInitiatorQueue with status = on
go
create queue MyServiceExecuterQueue with status = on
go


-- SERVICES
create service MyInitiatorService on queue MyServiceInitiatorQueue ([http://mydomain.net/services/myservice/contractV1])
go
create service MyExecuterService on queue MyServiceExecuterQueue ([http://mydomain.net/services/myservice/contractV1])
go

-- permissions
grant RECEIVE ON MyServiceInitiatorQueue to public
go
grant RECEIVE ON MyServiceExecuterQueue to public
go

Uma vez que as filas estejam definidas, devemos decidir como as mensagens vão ser recebidas peles executores e clientes. Existem várias alternativas para isto, a mais simples seria usar stored procedures para processar mensagens de cada lado. No nosso caso, isto não atende pois temos regras de negócio complexas que devem ser executadas para cada mensagem, que estão implementadas em nosso Domínio e não faria sentido ou seria viável repeti-las em procedures. Assim precisamos de algo que seja capaz de chamar uma regra de negócio dentro do nosso ambiente transacional.

A segunda possibilidade é utilizar o Service Broker External Activator, que é uma ferramenta disponibilizada pela Microsoft para estes cenários. Ele fica “escutando” as filas e se encarrega de chamar um executável externo que, no nosso caso, seria um código em C#. Em nossos testes, funcionou perfeitamente nos nossos ambientes de desenvolvimento e homologação, mas qual a nossa surpresa ao ver que no ambiente de produção ele simplesmente não funcionou. Depois de muito pesquisar, descobrimos que ele não funciona em Clusters de SQL Server, que é exatamente o cenário usado no ambiente de produção do nosso cliente.

A terceira possibilidade, a mais complexa, é utilizar código CLR embutido dentro do SQL Server. Há várias versões do SQL Server é possível compilar uma DLL e registrá-la para uso dentro de um database como se ela fosse uma stored procedure. Esta foi a alternativa escolhida para nosso cenário.

Só recapitulando o procedimento para incluir um código CLR no SQL Server: primeiro, é necessário criar um projeto com uma classe estática e um método estático, que vai ser o ponto de entrada para a chamada no SQL Server, decorado com o atributo Microsoft.SqlServer.Server.StoredProcedure. Depois este assembly deve ser registrado no database e finalmente as queues devem ser modificadas para acionar este método quando uma mensagem chegar. Um exemplo de código CLR e script estão a seguir. Lembrando que caso o assembly não seja assinado com um certificado confiável para o servidor onde está o SQL Server, é necessário baixar o nível de confiança do banco (primeira instrução do script abaixo). Como nossos assemblies não estavam assinados, optamos por fazer isto. Esta decisão deve ser tomada com responsabilidade, pois este comando vai aumentar a vulnerabilidade do banco de dados.

using Microsoft.SqlServer.Server;

namespace MyNamespaceInAssembly {
    public static class StoredProcedures {

        [SqlProcedure]
        public static void ProcessMessages() {
            Domain.Services.ProcessMessages();
        }
    }
}

Script:

-- Allows unsigned Assemblies
ALTER DATABASE ServiceBroker SET TRUSTWORTHY ON
GO

-- Register Assemblies
CREATE ASSEMBLY MyServiceThinClient from 'c:\myservice\ThinClientProcessor.dll' WITH PERMISSION_SET = UNSAFE
go
CREATE ASSEMBLY MyServiceExecuter from 'c:\myservice\ExecuterProcessor.dll' WITH PERMISSION_SET = UNSAFE
go

-- procedures
CREATE PROCEDURE ProcessMessagesThinClient
AS
EXTERNAL NAME MyServiceThinClientAssembly.[MyNamespaceInAssembly.StoredProcedures].ProcessMessages
go
CREATE PROCEDURE ProcessMessagesExecuter
AS
EXTERNAL NAME MyServiceExecuterAssembly.[MyNamespaceInAssembly.StoredProcedures].ProcessMessages
go

-- permissions
grant execute on ProcessMessagesThinClient to public
go
grant execute on ProcessMessagesExecuter to public
go

-- activations
alter queue MyServiceInitiatorQueue with activation( procedure_name = ProcessMessagesThinClient, MAX_QUEUE_READERS = 1, status = on, execute as self)
go

alter queue MyServiceExecuterQueue with activation( procedure_name = ProcessMessagesExecuter, MAX_QUEUE_READERS = 1, status = on, execute as self)
go

Por enquanto é só pessoal. Na parte 3 vou detalhar melhor o código do ProcessMessages, tanto do ThinClient quanto do Executor. Se tiverem dúvidas específicas, podem entrar em contato. Até a próxima!

Arquitetura de Microservices utilizando o Microsoft SQL Service Broker – Parte 1

Olá pessoal, vou iniciar uma série de posts mais técnicos desta vez. Como mencionei no post anterior, estivemos analisando o uso do Microsoft SQL Server Service Broker como uma alternativa para implementação de Arquitetura de Microservicess. Aproveitando uma necessidade de um de nossos clientes, conseguimos definir e implementar um barramento de microservices com sucesso, que já está em execução em ambiente de produção! Nesta série de posts vou detalhar a arquitetura utilizada, tentando mencionar os desafios que enfrentamos e as soluções adotadas. Espero que sirva de apoio para outros desenvolvedores se aventurando por esta linha.

Inicialmente um pouco de contexto. Em um de nossos clientes, da área financeira, possuímos um grande sistema .NET, em operação há mais de 20 anos. Apesar dele ser relativamente bem estruturado (separação de camadas, mapeamento objeto-relacional com nHibernate, interfaces MVC etc.), ele acumulou, por todo este tempo de evolução, uma infinidade de regras de negócio para cada uma das áreas atendidas. Por ser um sistema central da empresa, praticamente todas as operações passam pelo mesmo e ele é integrado à vários outros, por diversas formas de comunicação. Assim, temos cada vez mais dificuldade para evoluí-lo e mantê-lo, já que sua arquitetura monolítica faz com que testes de integração e homologação sejam extremamente complexos e demorados. É com grande dificuldade que conseguimos manter um ritmo saudável de trocas de uma metodologia ágil, pois o tempo de homologação de usuários quase que inviabiliza nossas janelas semanais.

Outro grande problema de nosso sistema monolítico é a escalabilidade. Com o aumento de demanda, não temos opção a não ser aumentar o número e capacidade de máquinas, pois o sistema tem que ser replicado por inteiro. gerando aumento de custos e complexidade de infra-estrutura.

Este seria um dos típicos problemas resolvidos por um sistema que utiliza uma arquitetura de microservices. Cada área de um sistema de grande porte seria implementada por um serviço independente, que usa um barramento de mensagens para comunicação entre si (ver figura a seguir). Desta forma, a manutenção ou evolução de uma área não afetaria outras, tendo seu próprio ciclo de desenvolvimento independente.

Porém, é raro termos o luxo de projetarmos um sistema do zero já incorporando este tipo de arquitetura. Então, nosso primeiro desafio foi achar uma maneira de fazer com que um sistema monolítico como o nosso pudesse utilizar microservices sem que ele tivesse que ser refeito do zero. A solução que encontramos está mostrada na figura a seguir. Inicialmente, isolamos uma área que possa ser implementada como um serviço isolado (A). Depois, quebramos este bloco em duas porções: uma pequena interface de comando e recepção de resultados (“Thin” API); e o módulo que implementa os executores de ações e regras de negócio específicas (B). Entre estes blocos, incluímos o suporte ao envio e recepção de mensagens, para que a API se comunique com o executor através do barramento de microservices (C).

Desta forma, conseguimos alguns benefícios da arquitetura de microservices: 1) o executor é completamente isolado do sistema principal, podendo ser evoluído de maneira independente; 2) a execução de atividades passa a ser feita de forma assíncrona, liberando recursos para o sistema e permitindo a escalabilidade horizontal dos executores. Se conseguirmos isolar cada área desta forma poderemos, a longo prazo, quebrar nosso sistema monolítico em vários microservices, chegando bem próximo de um sistema que fosse projetado do zero para esta arquitetura.

Pode-se argumentar que outras arquiteturas poderiam gerar benefícios similares. Uma alternativa, por exemplo, seria fazer uso de componentes intercambiáveis. Embora isto garantisse o isolamento da área de negócio, não resolveria por completo a questão da substituição em produção. Com microservices, podemos parar um dos executores de serviço, ou mesmo todos eles e todo o sistema continua funcionando normalmente (as mensagens simplesmente se acumulam, sendo processadas posteriormente quando o serviço for restabelecido). No caso de componentes, seria muito mais complexo de resolver este cenário, pois há um acoplamento direto entre o mesmo e o sistema; se o componente parar o sistema também para. Com componentes também não teríamos solução trivial para o problema de escalabilidade.

Outra alternativa seria o uso de webservices tradicionais, baseados em SOAP ou outro protocolo. Webservices simplificam o problema da substituição em produção, pois podemos ter um cluster de servidores, com vários em paralelo, e ir substituindo aos poucos, com o uso de versionamento. Eles resolvem também o problema de escalabilidade, pois são de menor porte e podemos aumentar o cluster conforme necessário. O grande problema de webservices é a latência que existe para as chamadas de regras de negócio, já que eles normalmente se encontram em outros servidores. Para ações muito frequentes, em operações comuns do sistema, poderíamos ter uma demora excessiva para a execução, afetando o usuário. E operações assíncronas em sistemas web chamando webservices são extremamente difíceis de serem implementadas.

Analisando estes e outros cenários, a arquitetura de microservices parece ser a mais adequada. Da mesma forma que um webservice, ela separa a camada de negócios, permitindo escalabilidade e isolamento. E é tão rápido quanto um componente, já que a sua “Thin” API reside dentro da aplicação. É claro que o lado negativo é que todas as operações, que antes eram síncronas, passam a ser assíncronas. Este é o maior limitador, já que é necessário reimaginar o comportamento do sistema considerando que as ações não são mais imediatas, mofidifcando a usabilidade do mesmo.

Para a implementação do nosso barramento de serviços, foi considerado o uso vários produtos, open source e comerciais. O RabbitMQ foi uma das alternativas que foram melhor avaliadas. No entanto, no final, a escolha foi o Microsoft SQL Server Service Broker. As razões foram a facilidade de se montar um barramento de serviços simples e o fato dos nossos sistemas já o usarem o SQL Server como DBMS, o que simplificou bastante nossa infraestrutura.

Bom, por hoje é só. Em breve devo detalhar a parte técnica da solução, desde a implementação das filas de mensagens e processadores até o processo de ativação de executores. Até a próxima!