Microservice Architecture là gì? Tại sao bây giờ chúng ta cần đến nó

I. Giới thiệu

Mình đoán chắc hẳn là rất nhiều người đã từng có một câu hỏi giống mình "Microservice là cái gì?", hay "Tại sao bây giờ mới là Microservice mà không phải là từ ngày xưa, từ cái ngày mà mình mới bắt đầu học code?". Và cơ bản mỗi khi nghe đến Microservice thì mọi người đề có một cảm giác rất mơ hồ. Và mình đã dành khá nhiều thời gian tìm hiểu về nó, và cũng may mắn được thử sức với một vài hệ thống microservice nên mình cũng xin phép có một chút chia sẻ, để mọi người có thể hiểu hơn về Microservice Architecture nhé.

II. Background

Để nói chính xác về bối cảnh của Microservice hay lịch sử v.v... thì chắc hẳn sẽ khá là khó hiểu, và khó nhớ nên mình sẽ giải thích một cách dễ hiểu nhất để ai cũng có thể nắm bắt một cách cơ bản nhất, kèm theo keyword để giúp các bạn có thể tự research sâu hơn. Bây giờ chúng ta mới nghe đến thuật ngữ Microservice nhiều hơn, vậy trước đó chúng ta sử dụng architecture gì? Đó chính là Monolith. Vậy Monolith là gì? Google translate thì nghĩa là đá nguyên khối =))))) tách nghĩa ra thì thấy có cụm "mono" - thì nghĩa là đơn (giống kiểu loa đơn (mono) - loa đôi là (stereo)) đó. Từ đó thì chúng ta có thể hiểu nôm na là mọi thứ chúng ta sẽ build trên 1 hệ thống, single codebase, tất cả sẽ được compile và deploy một cách đồng thời.

III. Vậy thì tại sao bây giờ Monolith lại trở nên lỗi thời?

Đầu tiên đó chính là sự phát triển của mạng Internet, đã bắt đầu nhen nhóm về microservice từ những năm 2004, nhưng chưa quá nổi bật. Nhưng đến những năm gần đây với sự bùng nổ của công nghệ với Smartphone, Wifi v..v.. dẫn đến việc con người ngày càng tiếp cận với các dịch vụ công nghệ nhiều hơn, nhiều business công nghệ xuất hiện nhằm đáp ứng nhu cầu hiện nay. Thay vì trước đây chỉ có những hệ thống nhỏ, với những trang tin tức, thông tin, với lượng truy cập và tương tác không quá lớn, thì bây giờ là những dịch vụ mạng xã hội, fintech, phát triển đòi hỏi sự phát triển càng ngày càng nhanh để đáp ứng nhu cầu ngày càng tăng đến từ người dùng. Do đó, sự bất lợi và những nhược điểm của Monolith bắt đầu xuất hiện.

IV. Nhược điểm của Monolith

1. Application Scaling:

Cùng với sự tăng trưởng theo cấp số nhân của các các công ty dịch vụ, thì nhu cầu mở rộng phần mềm của chính họ cũng ngày càng tăng lên. Ví dụ như, Facebook ban đầu với lượng người dùng chỉ là sinh viên của trường Havard nhưng bây giờ với sự phát triển mạnh mẽ thì họ cần mở rộng hệ thống để có thể chịu tải đc với số lượng User nhiều hơn rất nhiều. Do đó khả năng scaling là một điều cực quan trọng đối với các application hiện nay, và đó lại là điều mà monolithic application không làm được

2. Development Velocity:

Trong thời điểm hiện nay thì chắc hẳn là tất cả các công ty đều muốn phát triển các features một cách nhanh nhất. Tuy nhiên ở một hệ thống phức tạp và lớn thì việc thêm một feature sẽ rất chậm, đặc biệt là với Monolithic Application. Áp dụng công nghệ mới khó khăn vì toàn bộ ứng dụng phải thay đổi. Do đó nhiều ứng dụng một khối thường phụ thuộc một công nghệ cũ và lỗi thời, dẫn đến việc thay đổi sẽ tốn nhiều thời gian và tiền bạc. Và với đặc thù các công ty hiện nay là vừa và nhỏ, phần lớn là start-up thì việc thay đổi spec liên tục để phù hợp với nhu cầu của thị trường sẽ dẫn đến việc Monolithic Application khó có thể đáp ứng được nhu cầu

3. Development Scaling:

Các công ty thường mong muốn các sản phẩm hoặc các business của mình thường được phát triển song song để giảm thiểu thời gian phát triển, tuy nhiên với một hệ thống nguyên khối thì dù có tuyển thêm rất nhiều developers thì vẫn không thể giải quyết được vấn đề, vì khi xử lý code, logic, hay infrastructure sẽ liên quan đến các phần code khác do đó đôi khi dẫn đến phải chờ đợi nhau, conflict v..v. Ngoài ra, với những hệ thống Monolithic thì việc những developer mới tham gia dự án hay những member trẻ mới ra trường sẽ rất khó nắm cả một hệ thống lớn và phức tạp như vậy.

4. Release Cycle:

Thời gian release cho một hệ thống Monolithic lớn thường rơi vào khoảng 6 tháng chưa kể thời gian delay do một số yếu tố khác nhau. Hiên jthay thì thời gian release ảnh hưởng rất nhiều đến các yếu tố cạnh tranh của các công ty. Ví dụ điển hình như những app thương mại điện tử lớn như Lazada hay Tiki họ có rất nhiều event cho ngày 09/09, 10/10, 11/11 hay 12/12. Nếu như development team vẫn sử dụng theo cấu trúc Monolithic thì liệu có thể đảm bảo release feature trong một khoảng thời gian ngắn hay không?

5. Modularization:

Các component được liên kết chặt chẽ với nhau dẫn đến side effect không mong muốn như khi thay đổi một component ảnh hưởng đến một component khác. Toàn bộ ứng dụng cần được triển khai lại cho bất kỳ thay đổi nào. Không hề dễ để hiểu project do các module liên quan chặt chẽ lẫn nhau. Một issue nhỏ cũng có thể làm chết toàn bộ ứng dụng.

IV. Microservice Architecture

Trong khoảng thời gian trở lại đây thì có rất nhiều công nghệ mới được ra mắt và đã ảnh hưởng rất nhiều đến việc phát triển phần mềm ví dụ như Cloud Computing, Containerization (Docker, Kubernetes), DevOps. Cùng với đó là sự xuất hiện của rất nhiều ngôn ngữ lập trình mới, ví dụ như Golang, Rust, Swift cùng với sự tiện lợi, dễ sử dụng giống như các ngôn ngữ như là JavaScript, Python. Một vài sự thay đổi về Software Development model, Waterfall software development model iần như bị loại bỏ và được thay thế bằng phương pháp phát triển phần mềm nhanh, lặp, tăng dần: Phát triển phần mềm Agile. Phần cứng máy tính ngày càng rẻ hơn, nhanh hơn và sự phát triển CPU Multi-Core, GPU. Những sự thay đổi về CSDL mới như là NoQuery, New Query nổi lên và trở thành xu hướng.

Để xử lý những vấn đề trên, cùng với những lợi thế đến từ Cloud Computing, Containerization, DevOps, modern Programming languages và đến từ nhu cầu phát triển phần mềm hiện đại (fast development, horizontal scaling), một Software Architecture Style được phát triển từ năm 2012: Microservice Architecture. Vậy, Microservice Architecture chính xác là gì? Có rất nhiều định nghĩa về Microservice Architecture và dưới đây là định nghĩa của bản thân mình về nó

Kiến trúc microservice là về việc phân tách hệ thống thành các đơn vị nhỏ hơn có thể triển khai độc lập và giao tiếp thông qua cách thức khá đơn giản, với ngôn ngữ mới nhanh, nhẹ và cùng nhau hoàn thành business một cách nhanh nhất và tốt nhất.

Kiến trúc microservice cũng sử dụng cùng một kỹ thuật (Divide and conquer) để giải quyết sự phức tạo trong các hệ thống, và nó cũng giống như Monolithic architectrure nơi mà những hệ thống phức tạp được chia thành nhiều Microservices với khả năng giao tiếp thông qua những external interface. Điểm khác nhau chính giữa Modular Monolithich và Microservice Architecture là ở việc mọi Microservice đều có thể được deploy một cách độc lập, trong khi với Modular Monolith là các module phải deploy đồng thời. Các bạn có thể hiểu 1 cách đơn giản thông qua hình ảnh dưới đây

Monolithic application là một single unit (tightly coupled) giống như một miếng (cube) trong rubik. Modular application thì giống như Rubik nơi mà bao gồm rất nhiều các module nhỏ, tuy nhiên các module này không thể phân tách nhỏ mà phải deploy đồng thời. Còn Microservice thì giống như những miếng lego vậy, chúng ta có thể dễ dàng chia nhỏ và lắp chúng lại để thành một khối lớn. Do đó chúng ta có thể deploy riêng từng service, sau đó mới kết nối chúng vào với nhau, sẽ không làm giảm ảnh hưởng đến hệ thống hiện tại.

V. Ưu điểm của Microservice

1. Application Scaling:

Đầu tiên, microservices phần lớn đều là stateless (để hiểu thêm các bạn có thể search thêm về stateful và stateless) and nếu bạn sử dụng Docker, Kubernetes hoặc sử dụng Infrastructures, Microservices có thể horizontal Scaling chỉ trong 1 vài giây. Trên thực thế, the high horizontal Scaling (scale theo chiều ngang) đã được sử dụng ở rất nhiều công ty lớn như là Netflix, Spotify, Uber, Google chuyển từ kiến trúc Monolithic sang Microservice để đảm bảo sự phát triển của business của họ. Thứ 2, sẽ phân bố và tối ưu được hệ thống tốt hơn, ví dụ nếu một microservice ví dụ như xử lý chuyên sâu về ngôn ngữ máy, CPU thì nên sử dụng đặc thù những ngôn ngữ có khả năng tối ưu cho hoạt động với CPU ví dụ như (C/C++, Rust), hoặc với những microservice implement logic, hoặc server sẽ được tối ưu bằng các ngôn ngữ lập trình để có thể dễ thay đổi, dễ làm việc đối với developer (Java, PHP, Ruby on Rails).

2. Development Speed:

Microservice thường có kích thước khá nhỏ (vài trăm đến vài nghìn). Do kích thước, việc thêm các tính năng mới trong microservice thường nhanh hơn.

3. Development Scaling:

Microservices có khả năng tự chủ và có thể được phát triển một cách độc lập. Do đó, khả năng scale (phát triển, mở rộng) sẽ tốt hơn cho các developers/teams có thể làm việc với những môi trường ít bị ảnh hưởng bởi những môi trường khác. Hiểu đơn giản là chia để trị, nên việc mở rộng sẽ dễ dàng hơn. Vì vậy, các công ty có thể dễ dàng thuê nhiều developers hơn và có thể mở rộng quy mô. Tương tự, do kích thước của chúng, và sự đặc thù sẽ giúp cho các developers có thể nắm bắt và hòa nhập nhanh hơn với dự án và với code. Vì đơn giản đây chỉ là một phần kiến trúc khá nhỏ để xử lý, hơn là phải hiểu một hệ thống rất to và lằng nhằng như Monolithic.

4. Release Cycle:

Theo cá nhân mình, thì một trong những features tuyệt vời nhất của Microservice Architecture là mọi Microservice đều có thể được deploy một cách động lập. Từ đó, Software Release Cycle trong Microservice Applications sẽ nhỏ hơn, đơn giản hơn với CI/CD, và có thể release theo ngày/tuần, điều mà Monolithic khó mà có thể làm được.

5. Modernization:

Với sự phát triển ngày càng nhanh của công nghệ thì việc thay đổi công nghệ là điều xảy ra liên tục, do đó với microservice thì việc thay đổi công nghệ sẽ dễ dàng hơn với việc phát triển công nghệ mới trên một module mới rồi sau đó chỉ việc kết nối vào thì sẽ dễ dàng hơn rất nhiều so với trước đây. Với Monolithic thì việc này đôi khi là cực kì khó khăn, do việc xử lý hệ thống, logic, coding liên quan mật thiết đến nhau đôi khi việc thay đổi là không thể, dẫn đến ảnh hưởng đến business hoặc tốn rất nhiều chi phí và thời gian để xây dựng lại một hệ thống hoàn toàn mới.

VI. Những nhược điểm của Microservice

Giống nhữ mọi thứ trên cuộc sống này đều có hai mặt của nó và Microservice Architecture cũng vậy. Microservice giải quyết được rất nhiều vấn đề mà các business đang gặp phải, giải quyết những bất lợi mà Monolithic đang gặp, tuy nhiên nó không hẳn là một chiếc chìa khóa vạn năng cho tất cả các hệ thống, và không phải lúc nào cứ sử dụng Microservice là tốt là chuẩn, mà đôi khi chúng ta cần phải cân bằng và tìm được kiến trúc phù hợp nhất đối với nó. Mình có rành một chút thời gian đọc về một số bài viết về nó ví dụ “Building Microservices” , “Goodbye Microservices: From 100s of problem children to 1 superstar” hoặc “The Death of Microservice Madness in 2018" nơi mà các tác giả đã nêu lên những bất cập mà microservice đang có và chúng ta cần biết đặc biệt là trước khi chuyển từ Monolithic sang Microservice. Dưới đây là một số nhược điểm mà mình đã chắt lọc được:

1. Design Complexity:

Kiến trúc Monolithic đem đến cho chúng ta một solution kiểu “One size fits for all” cho các business application, Ví dụ, nếu Web application của bạn có hàng ngàn dòng code thì với Monolithic Architecture sẽ đưa cho bạn các solution khá là giống nhau (Enterprise Java or Ruby on Rails or PHP). Nhưng với Microservice Architecture, sẽ có rất nhiều giải pháp (possible solutions) để giải quyết vấn đề của bạn phụ thuộc vào đặc thù business, nhu cầu của khách hàng v..v.. Do đó, nếu chúng ta áp dung một giải pháp không "chuẩn" thì sẽ dẫn đến nhiều vấn đề (ví dụ đơn giản là mua một chiếc áo size trẻ con cho một người trưởng thành hoặc ngược lại vậy) chúng sẽ đem đến nhiều hệ quả về business (trải nghiệm người dùng, doanh thu v..v). Từ đó, design microservice architecture đòi hỏi phải rất kĩ càng và cần những người ngaoif việc có kinh nghiệm và chuyên môn cao còn phải hiểu được bản chất của business và khách hàng của mình, điều mà cá nhân mình nghĩ rằng không hề đơn giản, và không phải là ngày 1 ngày 2 chúng ta có thể design đc chính xác hoàn toàn. Nhìn ngược lại với Monolithic, đôi khi việc phát triển sẵn những package, sẽ đi kèm với sự support tận tình từ chính những nhà phát triển và từ đó sẽ giảm thiểu sự khó khăn ban đầu khi thiết kế hệ thống.

2. Distributed Systems Complexity:

Microservice được biết đến như là một dạng hệ thống phân tán (distributed system) và chắc hẳn chúng ta nghe thôi đã thấy nó khá là lằng nhằng và nhức đầu rồi (đôi khi kể cả chưa biết gì), và đúng thực sự nó khá là phức tạp. Mình sẽ không nói nhiều về distributed system nhưng với nó thì nó có rất nhiều những khó khăn mà chắc hẳn với những người chưa có nhiều kinh nghiệm sẽ rất khó để có thể giải quyết và vượt qua.

3. Security:

Security trong Software Systems thường là một cái gì đó mà ai cũng có thể nhìn thấy nhưng không ai muốn nhắc đến nó. Bảo mật một ứng dụng đã khó, vậy thì khi bảo mật một tập các microservice khác nhau cùng vô số liên kết phân tán thì thực sự là một điều gì đó không hề tầm thường.

4. Data Sharing and Data Consistency:

Trường hợp lý tưởng nhất là mỗi microservice nên có một Data Store cho riêng mình. Nhược điểm là Microservice cần chia sẻ dữ liệu lẫn nhau để đảm bảo được Business Goal. Tính nhất quán dữ liệu là một thách thức bởi vì việc đồng nhất dữ liệu đặc biệt với dữ liệu lớn không hề đơn giản

VII Tổng kết

Có vẻ bài viết này ban đầu có vẻ dễ hiểu nhưng càng về sau lại càng trừu tượng, 1 phần vì chính chủ đề về microservice sẽ làm cho mọi người khá mơ hồ và hơi khó tưởng tượng. Chưa kể một số đề mục mình lại để tíếng anh, nhưng đơn giản vì mình cũng không rõ dịch kiểu gì nữa. Trong bài viết tới mình sẽ liệt kê về các case study cụ thể hơn để mọi người có cái nhìn nó bớt mơ hồ hơn. Cám ơn các bạn đã đón đọc và xin lỗi các bạn vì bài viết có vẻ hơi khó hiểu