thảo luận Microservices and Cloud Native Group

RPG29

Đã tốn tiền
Thấy nhiều bác đang làm việc với Microservices và Cloud Native nên em lập topic này để chia sẻ kinh nghiệm và có chỗ cho mọi người chém.
Microservices và Cloud Native là chủ đề rất rộng nên em sẽ từ từ chia nhỏ nó ra thành từng mục cho mọi người dễ follow.
Những cái em chia sẻ hầu hết là kinh nghiệm cá nhân khi triển khai và những gì em nghiên cứu được nên sẽ có đúng có sai, các bác cứ gạch nhiệt tình.

Về ngôn ngữ lập trình thì trước giờ em từng làm việc với Java, Python, PHP và mới đây là Go cho nên em sẽ trả lời cụ thể nếu liên quan còn với những ngôn ngữ khác thì em chỉ có thể tư vấn giải pháp chung chung.

:byebye:


Richardson-microservices-part1-2_microservices-architecture.png


Giới thiệu sơ qua với các bác về kinh nghiệm làm việc với Microservices và sau này là Cloud Native của em.

Em bắt đầu nghiên cứu xây dựng hệ thống lớn và scalability từ khoảng cuối năm 2012, thời điểm đó ở VN vẫn chưa thấy có ai nhắc tới từ Microservices. Thời điểm đó các tài liệu về xây dựng hệ thống, vận hành, scale... không nhiều và hầu hết em đọc là từ http://highscalability.com. Thằng này nó đưa đẩy dẫn lối cho em từ lúc đó, đam mê nghiên cứu kiến trúc hệ thống. :byebye:

Khoảng đầu 2013 thì em đi làm chính thức ở một dự án mà bây giờ là một cty thương mại điện tử top của VN. Lần đầu tiên mới được tiếp xúc với các quy trình phát triển, triển khai, vận hành, scale, system... trong thực tế. Sau đó thì em nhảy lóc cóc mấy công ty cho đến khi bắt đầu tham gia một dự án mà em là người trực tiếp thiết kế vận hành nó.

Khởi đầu thì hệ thống em triển khai nó viết bằng PHP 5.6, MySQL 5.6. Nó là một cục monolithic to bự viết bằng Symfony 2.x, chạy trên nền PHP-FPM, Nginx, CentOS 6.x từ khoảng giữa năm 2014.
Hồi mới start cũng chỉ mang tính chất prototype nên mọi thứ không được chú trọng thiết kế cho lắm, miễn sao release nhanh ra chạy lấy feedback là được rồi.

Hệ thống chạy được vài năm cho đến khoảng năm 2018 thì biz model tương đối ổn định. Biz model mở rộng và phát sinh một số nhu cầu đặc biệt kèm theo đó là code base 4 năm tuổi viết từ cái hồi còn prototype nên việc maintenance rất cực khổ nên anh em quyết định đập nhỏ và migrate dần từng phần sang kiến trúc mới.

1. Môi trường triển khai microservices

Hiện nay cứ nói đến triển khai microservices thì mọi người mặc định nghĩ đến Docker. Thực tế thì Docker chả liên quan gì microservices nhưng mà Docker là công cụ tốt nhất hiện nay giúp cho việc triển khai microservices được dễ dàng.

Trước kia khi làm việc với PHP thì chủ yếu em deploy bằng Capistrano - cái này giờ chắc ít người biết, mấy bác làm Ruby hồi xưa chắc biết thằng này, nó kiểu giống như Ansible hay Fabric.

Em làm việc với Docker từ khá sớm khoảng năm 2014, hồi đó hệ sinh thái Docker nói riêng và container nói chung rất ít công cụ. Chuyển sang sử dụng Docker là một trong những bước nhảy vọt lớn nhất trong quá trình làm việc cho đến lúc đó. Hồi đó triển khai Docker trên production thật sự khá là cực vì không có nhiều đồ chơi như bây giờ. Em cũng có dùng qua Rancher nhưng thấy không ổn nên thôi.

Từ lúc sử dụng Docker thì học thêm được các phương pháp triển khai ứng dụng hiện đại https://12factor.net/

Thực ra thì ngoài Docker cũng có một số thằng khác:
  • Rkt: thằng này của CoreOS mà chết rồi, không cần quan tâm.
  • Podman/Buildah: thằng này mới nổi, có nhiều ưu điểm hơn Docker và đang được Redhat chống lưng nên khá có tiềm năng.

2. Công cụ quản lý container

Chỉ với Docker thì bạn vẫn có thể triển khai ở quy mô nhiều node nhưng khi số lượng node tăng lên hoặc cần tự động hóa thì phải cần thêm công cụ quản lý, những công cụ này gọi là Container Orchestrator.

Có nhiều công cụ như K8s, Nomad, Mesos... Phổ biến nhất hiện nay là K8s nhưng mình chọn Nomad của HashiCorp vì đơn giản, dễ dùng, triển khai trong vài bước cơ bản.

// TODO
 
Last edited:
Cho mình hỏi ngu, mà mình cũng hỏi chơi thôi chứ cũng ko đang làm về MicroService:

- Trước mình luôn nghĩ là các service giao tiếp bằng API Rest/SOAP, vậy mà mấy hôm nay đọc được khái niệm "Service Bus", vậy cái này là gì vậy.

- Load Balancer là cái gì vậy. Mình đọc thì hiểu là "router làm nhiệm vụ route các request đến các server khác nhau", mà k biết đúng k.
 
Cho mình hỏi ngu, mà mình cũng hỏi chơi thôi chứ cũng ko đang làm về MicroService:

- Trước mình luôn nghĩ là các service giao tiếp bằng API Rest/SOAP, vậy mà mấy hôm nay đọc được khái niệm "Service Bus", vậy cái này là gì vậy.

- Load Balancer là cái gì vậy. Mình đọc thì hiểu là "router làm nhiệm vụ route các request đến các server khác nhau", mà k biết đúng k.

Service Bus là một cái pattern có từ rất lâu rồi. Bác có thể nghe đến Enterprise Service Bus hay ESB chính là nó.
Cơ bản nó là một con đường để vận chuyển data giữa các service. Ví dụ có một thằng rất nổi tiếng là Apache Camel.
ESB thì em chưa dùng thực tế bao giờ chỉ biết vậy thôi. Nó có thể được implement bằng mấy thằng message broker như RabbitMQ, Kafka...

Load Balancer là một hardware hay software có nhiệm vụ distribute request/workload đồng đều giữa các service instance hay server.
 
theo bạn một product thì khi nào cần áp dụng microservices :-?. Có nên build nó từ ban đầu không :-?
 
theo bạn một product thì khi nào cần áp dụng microservices :-?. Có nên build nó từ ban đầu không :-?

Product cần áp dụng microservices khi nó cần :byebye:

Cái này nó tương đối phụ thuộc vào nhu cầu và hoàn cảnh quá mình không đưa ra ý kiến được.

Khởi đầu thì nên làm monolithic cho khỏe, vì khi đó chưa xác định được rõ bounded context. Cứ làm mono rồi break down micro sau.
 
Last edited:
Sau đó thì em nhảy lóc cóc mấy công ty cho đến khi bắt đầu tham gia một dự án mà em là người trực tiếp thiết kế vận hành nó.

Khởi đầu thì hệ thống em triển khai nó viết bằng PHP 5.6, MySQL 5.6. Nó là một cục monolithic to bự viết bằng Symfony 2.x, chạy trên nền PHP-FPM, Nginx, CentOS 6.x từ khoảng giữa năm 2014.


// TODO

bác tự thiết kế từ đầu luôn hả? Nếu ngại cho tên cty thì có thể cho mình biết lĩnh vực hoạt động và quy mô của nó cỡ nào ko (so với mấy thằng cùng tier cho dễ) ? Traffic ra làm sao?
 
theo bạn một product thì khi nào cần áp dụng microservices :-?. Có nên build nó từ ban đầu không :-?
Theo mình là nên theo microservice ngay từ đầu nếu có thể, bằng cách áp dụng DDD để phân tách và gom nhóm các domain. Đương nhiên là luôn luôn có cách dễ dàng là làm monolithic rồi sau này phân tách thành microservice, mọi người đều nghĩ việc này khả thi cho đến khi thực sự đụng đến và kết quả là rewrite lại phần lớn
 
Theo mình là nên theo microservice ngay từ đầu nếu có thể, bằng cách áp dụng DDD để phân tách và gom nhóm các domain. Đương nhiên là luôn luôn có cách dễ dàng là làm monolithic rồi sau này phân tách thành microservice, mọi người đều nghĩ việc này khả thi cho đến khi thực sự đụng đến và kết quả là rewrite lại phần lớn

Đúng rồi bạn, phần lớn mình thấy đều rewrite thôi =] tốn kém vcl
 
Mong bạn viết Tutor cho cả Beginner nữa (Tất nhiên là có background về lập trình) cho mọi người đều có thể xem và học hỏi được.

Cám ơn bạn đã đóng góp bài cho box lập trình
 
Service Bus là một cái pattern có từ rất lâu rồi. Bác có thể nghe đến Enterprise Service Bus hay ESB chính là nó.
Cơ bản nó là một con đường để vận chuyển data giữa các service. Ví dụ có một thằng rất nổi tiếng là Apache Camel.
ESB thì em chưa dùng thực tế bao giờ chỉ biết vậy thôi. Nó có thể được implement bằng mấy thằng message broker như RabbitMQ, Kafka...

Load Balancer là một hardware hay software có nhiệm vụ distribute request/workload đồng đều giữa các service instance hay server.

Vậy service bus so với rest/soap là cũ hơn à.
Kafka hay message broker nói chung thì mình biết, trong mắt mình nó là cái buffer của một hệ thống data streaming, để cho những thằng chuyên xử lý stream như Spark Structured Streaming hay stream analytic chọc vào đọc, nhưng tại sao nó lại có thể dùng để giao tiếp giữa các service trong micro service nhỉ.

Các service viết các request vào 1 topic nào đó. Rồi các service đọc các topic đó, xem có request nào liên quan đến mình rồi xử lý, có phải là cái mà người ta nói là [event driven] sao? Nếu là làm thế này delay sẽ ra sao nhỉ. Trong mắt mình thì cái hành động write request vào một topic giống như thả 1 cái request trôi nổi vậy, ai đọc được lúc nào thì đọc, ko đảm bảo có ngay tí nào.

Load balancer ý là vd mình replicate cái application ra các web server khác nhau ra nhưng phải có một cái gì đó route vào các server gần nhất nhanh nhất, kiểu nếu ở VN thì route vào server Asia, còn ở Mỹ thì route vào server NA ấy nhỉ.
 
Vậy service bus so với rest/soap là cũ hơn à.
Kafka hay message broker nói chung thì mình biết, trong mắt mình nó là cái buffer của một hệ thống data streaming, để cho những thằng chuyên xử lý stream như Spark Structured Streaming hay stream analytic chọc vào đọc, nhưng tại sao nó lại có thể dùng để giao tiếp giữa các service trong micro service nhỉ.

Các service viết các request vào 1 topic nào đó. Rồi các service đọc các topic đó, xem có request nào liên quan đến mình rồi xử lý, có phải là cái mà người ta nói là [event driven] sao? Nếu là làm thế này delay sẽ ra sao nhỉ. Trong mắt mình thì cái hành động write request vào một topic giống như thả 1 cái request trôi nổi vậy, ai đọc được lúc nào thì đọc, ko đảm bảo có ngay tí nào.

Load balancer ý là vd mình replicate cái application ra các web server khác nhau ra nhưng phải có một cái gì đó route vào các server gần nhất nhanh nhất, kiểu nếu ở VN thì route vào server Asia, còn ở Mỹ thì route vào server NA ấy nhỉ.
mirco services sẽ có 2 cách giao tiếp:
- trực tiếp: gọi restAPI hoặc gRPC, ... dùng trong trường hợp cần response trả về ngay lúc đó ... ví dụ như khi service order và service user, khi order service cần thông tin user trả về theo cùng với response order service thì lúc này chúng ta cần thông tin gấp nên phải gọi trực tiếp, ...
- gián tiếp: dùng kafka(message system) hoặc rabbitMQ(message queue), ... dùng trong trường hợp không cần response cho service đang gọi ... thực hiện sau đó vài phút hoặc vài giờ ... ví dụ như e viết bài post và cần notify tới friends chẳng hạn thì không cần ngay lập tức ...

ở trên là ý kiến cá nhân em, mong các thým góp ý sửa sai ^^
 
Thím triển khai trên platform nào? Google Kubernetes, AWS...? Quá trình deploy từ dev lên staging và production ntn?
 
Thím triển khai trên platform nào? Google Kubernetes, AWS...? Quá trình deploy từ dev lên staging và production ntn?

Bên mình dùng GCP, dùng cả managed service lẫn on-premises.
Deployment thì model bên em rất đơn giản. Mỗi môi trường tương ứng với một branch trên git.

Vd có 3 môi trường develop -> staging -> production sẽ có 3 branch chính là develop / staging / master, master luôn là branch cho production.
Các engineer sẽ chia feature branch tùy ý và tích hợp liên tục vào develop branch. Khi cần lên môi trường cao hơn thì tạo PR merge rồi deploy thôi, gần như tự động hoàn toàn. Phần này mình sẽ chia sẻ kỹ hơn sau.
 
Back
Top