.NET Core Microservices using GeekseatBus

GeekseatBus is a simple message bus that can be use to create microservices in .NET.

Here’s the background why we do this on our own.

Background

A lot of microservices right now is in favour using REST API for communication between services. We are in geekseat take different approach for microservices and we avoid request response between services. This is align with SOA tenets for autonomous component. You component can’t be autonomous if you still using request response. If one service dies, other service is dies too. This will create temporal coupling between services.

We are a big fan of Udi Dahan style of microservices. As it enable high cohesion and loose couple on our big system. If you want to learn more you can register for 2 days course for free from here.

The central things from this approach is the needs of message bus. Message bus is used to communicate via fire and forget and also publish and subscribe between each services. So it promotes loosely coupling between each component.

Geekseat has been researching for simple message bus on RabbitMQ. We found NServiceBus and,  Mass Transit. But both of platform can’t be used in Linux. That’s a big problem for us as our backend currently written on .NET Core ( cross platform .net ). So we decide to create our own implementation of Message Bus on top of RabbitMQ.

We has published GeekseatBus to nuget. This is a big first start for us as we are start to open source our infrastructure for microservices.
We are a great believer of keeping thing simple and minimal configuration. As an agile company we like to see our simple stuff works in production. GeekseatBus also rely on convention over configuration. This will made things easier to use.

Getting Started

Ok, Let’s get started. Here’s the schema of what we are going to achieve on this head first with GeekseatBus.

From the above schema we can see that we have 2 services. Order Service and Billing Service. Order Service have 2 component which is Order Client and Order Service ( Server ).

Geekseat.BillingService subscribe to the OrderPlaced event published from OrderService and do it’s own thing by billing the customer according to the product ordered.

Fire and Forget Demo

Now let’s open our beloved Visual Studio IDE.

Create Solution and the .NET core console application for OrderService. This will be OrderService endpoint. This service will handle PlaceOrder command and publish OrderPlaced event.

Add reference to GeekseatBus nuget package to Geekseat.OrderService project.

Create class library project for messages. We have 2 messages, PlaceOrder command and OrderPlaced event. We have convention for naming the project. You should have project name that contain service name as prefix. Ex: If your service name is Geekseat.OrderService than your message project should be Geekseat.OrderService.Messages.

You also should have create two directory for events and commands like this one. This will give you the namespace for events ( Geekseat.OrderService.Messages.Events ) and for commands ( Geekseat.OrderService.Messages.Commands)

Create PlaceOrder command on Commands folder and OrderPlaced events on Events folder. And Delete Class1.cs.

Make the content of PlaceOrder.cs like this.

And the content of OrderPlaced.cs like this.

Please make sure that your namespace follow the conventions we mention above.

Create another endpoint for Geekseat.OrderClient.

Add GeekseatBus reference to Geekseat.OrderClient. Also add GeekseatBus.OrderService.Messages to OrderClient and OrderService.

Now we can start creating a message handler for PlaceOrder in OrderService.

On Program.cs ( in OrderService ) you should start the bus with this code. Really simple startup right ?

You can try to run the OrderService to see what convention is used on creating queue and exchange in rabbitmq. Basically each service will have it’s own queue ( single queue for handling multiple message). This queue can be bind to event that the service interested in.

A service can also create an exchange for the event it’s published. You can check that OrderService have a queue named Geekseat.OrderService and Exchange Geekseat.OrderService.Messages.Events.OrderPlaced.

Let’s now send some message to our service. Now we will concentrate on Geekseat.OrderClient.

Run both OrderService and OrderClient. And press enter to send the message from Client.

Voila, it receive the message !

Publish and Subscribe Demo

Now we will publish an OrderPlaced event from OrderService. The publishing will be handle in PlaceOrderHandler. We will inject IGsBus into this handler and do publishing.

Ok. Now let’s create subscriber for that event. We will leverage exchange in RabbitMQ. But of course this will be transparent from the user.

Create a new console project Geekseat.BillingService. Add reference to messages and GeekseatBus. Create message handler OrderPlacedHandler.

Add the service startup for BillingService and we’re done.

Run all the console application (OrderService, BillingService and OrderClient). Enter the message from OrderClient and you can see that the event has been published to BillingService.

It Works !

We have open source this library on Github. You can download, experiment and give a pull request !

Happy Microservicing 🙂

 

Cheers

 

 

 

Advertisement

NServiceBus vs WCF

Disadur dari NServiceBus Homepage

NServiceBus merupakan open source software yang dibuat oleh Udi Dahan (SOA expert). Tujuan si pembuat tentu saja untuk menjadikan NServiceBus sebagai alat yg membuat pembangunan aplikasi berorientasi service menjadi lebih mudah.

NServiceBus (NSB) dirancang untuk kolaborasi antar business-oriented services. NSB tidak bermaksud untuk menggantikan teknologi RPC seperti WCF. WCF tentu saja memiliki tempat pada arsitektur SOA tidak mungkin hanya menggunakan NServiceBus saja.

Nah NSB bukan merupakan service bus yg terpusat seperti BizTalk. Jadi NSB bukan terletak di tengah dimana komunikasi melalui central tersebut. Centralized communication seperti itu merupakan tanggung jawab dari Broker bukan Bus. Bus bukan tidak terlihat secara fisik. NSB lebih dekat ke WCF daripada ke BizTalk

SOA vs REST

SOA berdasarkan kepada konsep MEST atau MESsage Transfer. Message mengandung statement of intent dan data yg berhubungan dengannya. Contohnya adalah ChangeCustomerAddressMessage (message tersebut sudh menunjukkan maksudnya) dan di dalam object tersebut terkandung data yg berhubungan dengan maksud tersebut.

REST berfokus terhadap Resource. Jadi jika kita ingin merubah alamat dari Customer maka kita harus tahu URI dari Customer tersebut dan menyertakan method PUT dan datanya.

PUT http://example.com/customer1

PUT adalah method dan http://example.com/customer1 adalah URI

Service Autonomy 2

Autonomous = Otonomi = Mampu berdiri sendiri.

Autonomous service brarti service yg mandiri. Yg ingin dicapai sebenarnya dari prinsip tersebut adalah loosely couple. Misalkan service A membutuhkan service B maka meskipun Service B tidak tersedia Service A tetap dapat menjalankan fungsinya sesuai dengan service agreementnya. Sesuai dengan janjinya
Jadi caranya adalah menghilangkan request response collaboration pada level service. Jadi jika kita memiliki 2 software entities dimana kita harus melakukan request response brarti keduanya berada pada satu service. Tetapi harus digaris bawahi kata harus. Semua emang bisa dilakukan dengan Req/Resp tetapi ada bagian2 yg sebenarnya tidak.

Component Orientation dan Object Orientation membagi solusi menjadi bagian2. Jadi kita harus menemukan boundary yg tepat. Sehingga bagian2 yg sebenarnya dapat terpisah tidak couple.

REST design

Jika kita ingin membuat aplikasi web kita menjadi scalable maka kita harus dapat mengamati data yg kita sediakan dan bagaimana penggunaan user terhadap data tersebut. Nah jika kita dapat menganalisanya maka kita dapat menentukan mana data yg dapat dicache dan tidak. Karena memang protocol HTTP mendukung teknik tersebut dan bahkan di design untuk hal tersebut. Jadi kita tidak perlu membebani server terlalu berat karena ada bagian2 data yg dicache.

Kita dapat memberikan tanda bahwa page atau request tersbut dapat dicache atau tidak dari HTTP Header. Kita dapat mensetnya. Jadi apabila suatu URI dicache maka kali berikutnya dia dibutuhkan dia akan mengambil dari cache.