#micro-service

[nhattieu]

7 lý do sử dụng kiến trúc Micro-service

Mình dịch sơ để lưu lại trong đầu, sẵn tiện chia sẻ cho các bạn đang tìm hiểu Micro-service luôn.

Bài viết gốc ở đây: http://eugenedvorkin.com/seven-micro-services-architecture-advantages/

7 lý do sử dụng kiến trúc Micro-service

1. Nhỏ gọn, code đọc dễ hiểu. Bởi vì ứng dụng micro-service được xây dựng chỉ để xử lý 1 vấn đề cho nên có rất ít dòng code, vì vậy rất dễ hiểu & hạn chế rủi ro khi thay đổi. 2. Dễ dàng mở rộng (scale). Với ứng dụng monolithic (tạm dịch: nguyên khối), khi scale bạn sẽ phải scale cho tất cả mọi thứ. Ví dụ ứng dụng của bạn có 2 phần: tạo tài khoản và đăng nhập, bạn thấy phần tạo tài khoản có vấn đề, bạn không thể scale riêng cho phần tạo tài khoản mà phải scale cho cả hai, như vậy rất phí tài nguyên. Ngoài ra bạn sẽ không thể sử dụng tối ưu một số dịch vụ cho phép Auto-Scale tài nguyên (ví dụ: Amazon AWS). 3. Dễ dàng vứt bỏ. Công nghệ thay đổi liên tục, các ngôn ngữ lập trình, framework... hiện đại liên tục xuất hiện, và nhất là mã nguồn mở đang rất được ưa chuộng như hiện nay. Với kiến trúc micro-service bạn sẽ dễ dàng thay đổi, ứng dụng những ngôn ngữ, framework hoặc opensource mới... mà không làm ảnh hưởng đến ứng dụng hiện tại. Tất nhiên developer nào cũng muốn sử dụng công nghệ mới mà ^^. 4. Dễ dàng triển khai (deploy). Với các ứng dụng monolithic, chỉ với 1 dòng code bị thay đổi cũng phải deploy lại toàn bộ ứng dụng. Ít nhất là trên các nền tảng JVM. Với những website lớn, hoặc như các website thương mại điện tử thì việc gián đoạn hoặc bị lỗi gây thiệt hại rất lớn. Deploy một micro-service thì đơn giản hơn nhiều bởi vì phạm vi deploy rất nhỏ. Thêm nữa bạn sẽ dễ dàng tìm kiếm để fix lỗi hơn. 5. Sử dụng được nhiều nền tảng & ngôn ngữ. Đây là một lợi điểm rất lớn của kiến trúc micro-service. Như bạn biết mỗi ngôn ngữ, mỗi nền tảng đều có điểm mạnh & điểm yếu riêng. Ví dụ: micro-service recommendation nên sử dụng neo4j và Python bởi vì Python có rất nhiều thư viện machine-learning, event-processing micro-service nên sử dụng Java và Cassandra... Sử dụng micro-service bạn sẽ gỡ bỏ luôn rào cản ngôn ngữ (dễ tuyển dụng hơn, không tốn thời gian đào tạo, lợi dụng được sở trường của từng cá nhân...) trong phát triển ứng dụng. Thêm nữa, team của bạn sẽ dễ dàng thử công nghệ mới mà không ảnh hưởng nhiều đến hoạt động của ứng dụng. Một lần nữa, ai chẳng muốn dùng công nghệ mới :)) 6. Dễ dàng "chia để trị", ví dụ như một team chuyên làm về recommendation micro-service, một team chuyên về làm search micro-service chẳng hạn. 7. Khả năng phục hồi. Ứng dụng kiểu monolithic một khi bị sự cố sẽ kéo theo rất nhiều chức năng bị sự cố theo. Nếu mọi thứ đều là micro-service, một khi bị sự cố sẽ ảnh hưởng đến hệ thống ít hơn. Và bạn có thể ứng dụng các hệ thống Message Queue (như Gearman, RabbitMQ...) để tiếp tục xử lý các job sau khi phục hồi. Ví dụ: các đơn hàng được tạo trong thời gian Order Micro-service bị sự cố sẽ được lưu ngay sau khi nó phục hồi. Sướng quá còn gì nữa :D

Một số bài viết hay mà mình từng đọc:

1. http://microservices.io/patterns/microservices.html

2. blog.codescrum.com/2014/12/16/Microservices_with_RabbitMQ_and_Docker/

[prassee-blog]

Writing micro-services with Colossus

Micro-services has been the hot topic these days. There are handful of options that exist to write micro-services like Finagle,Spray etc.

I tried both Finagle and Spray but found that Finagle is more easy to write services than Spray. Though Spray is backed by the Akka actor model so Services could be written by extending Actor. Finagle on the other hand Finagle uses Futures.

For me I was looking for kind of framework combining the best of these worlds i.e a framework backed by actors and uses Futures like semantics. Thats how I found Tumblr's Colossus, in this post I am giving an intro on how to write a micro-service using Colossus.

Colossus is a micro-service framework which is purely built on Typesafe stack using the actor model.

To get started, in your build.sbt add the following

"com.tumblr" %% "colossus" % "0.6.1"

Lets build a micro-service using HTTP protocol

object HttpMicroService extends App { implicit val io_system = IOSystem() val responseTypes = List(("Content-Type", "application/json")) Service.serve[Http]("KVStore", 10200) { context => val kvs = KVStoreBackend context.handle { connection => connection.become { case request@Get on Root => Callback.successful(request.ok("{\"sim\" : \"data\"}", responseTypes)) case request@Get on Root / "api" / "create" / store => Callback.successful(request.ok("{\"status\" : \"" + kvs.createStore(store) + "\"}", responseTypes)) case request@Get on Root / "api" / store / key / value => Callback.successful(request.ok("{\"status\" : \"" + "saved" + "\"}", responseTypes)) case request@Get on Root / "api" / store / key => Callback.successful(request.ok("{\"result\" : \"" + kvs.readValue(store, key) + "\"}", responseTypes)) } } } }

the line which says

Service.serve[Http]("KVStore", 10200)

is where we define our service's protocol ,name and port where the service is supposed to run. Colossus relies on something called event loop so each request is executed within the event loop. However for writing a service we just need not worry about that but just create a implicit variable

implicit val io_system = IOSystem()

Like all other IO frameworks, the data is handled via a handler we create handler from the context there by obtain a connection which exposes a actor. We implement the behaviour of the service within this actor by using the become method.

We match for the URL pattern "/" by

case request@Get on Root => Callback.successful(request.ok("{\"sim\" : \"data\"}",responseTypes))

In the example I have KVStoreBackend which get initiated on the handler bootstrap. Lets implement creating a store by calling the url "/api/create/"

case request@Get on Root / "api" / "create" / store => Callback.successful(request.ok("{\"status\" : \"" + kvs.createStore(store) + "\"}"

In this post, I just scratched the surface by writing a service for a simple KeyValue store. In colossus a service could be a client for another service .

The code in this post is shared in Github.