Kiến trúc Monolithic là gì
Thay vì viết một bài hoặc một seri về Microservices, mình nghĩ nên recap luôn những vấn đề, thách thức, khó khăn khi chuyển đổi hệ thống Monolith lên Microservices. Show
Những kinh nghiệm này mình có được qua việc trải nghiệm với các hệ thống đã đang sử dụng Microservices cũng như tư vấn cho các đơn vị đang muốn chuyển đổi. Microservices là gì?Có lẽ các bạn đã nghe rất nhiều về từ khoá Microservices trong những năm gần đây. Thậm chí trong tuyển dụng phỏng vấn ứng viên frontend mà nhà tuyển dụng cũng kèm theo "biết Microservices" là một lợi thế. Ừ đúng là nó không liên quan thật. Kiến trúc MicroservicesMicroservices - còn được gọi là kiến trúc Microservice - kiến trúc này thường được sử dụng ở backend hay có hệ thống lớn. Để cho dễ hiểu, ngày trước backend code nguyên một cục rồi deploy lên server. Ngày nay người ta chia nó thành nhiều cục nhỏ hơn deploy riêng lẻ. Mấy cục nhỏ nhỏ này được kết nối để phục vụ chức năng nghiệp vụ vốn có. Vì sao cần chuyển đổi MicroservicesSẽ có vài câu chuyện rất quen thuộc trên công ty, à chính xác là ở team/bộ phận backend:
Đương nhiên sẽ không thể thiếu "vì hệ thống hiện tại đang chậm quá nên cần chuyển đổi lên Microservices". Nhưng đây là một trong những sai lầm phổ biến nhất!! Những sai lầm phổ biến về MicroservicesRất nhiều tổ chức đã chuyển đổi hệ thống lên Microserices xong lại phải chuyển về Monolith vì những vấn đề sau: Thiếu hụt hệ thống monitoringĐây là điều mình thấy khác ngạc nhiên rằng hầu hết các hệ thống đang có vấn đề điều thiếu hụt hoặc sơ sài thậm chí không hề có mornitoring. Hệ thống mornitoring giống như những cái ống nghe, điện tâm đồ trong ngành Y. Thời xưa, trước khi có những máy móc hiện đại, các lương y còn phải bắt mạch cơ mà. Không có công cụ mornitor hệ thống, bạn bị đau chân nhưng sẽ đi mổ tim, uống thuốc bổ phổi. Thật lạ là đó lại là điều đang diễn ra ở khá nhiều công ty công nghệ. Ví dụ hệ thống monitoring với GrafanaVì muốn hệ thống chạy nhanh hơnĐiều này nghe cực kỳ hợp lý, nhưng bản thân Microservices ra đời không vì lý do này. Trong định nghĩa của Microservices không hề có bất kỳ một chữ "faster" hay đại loại thế. Mà thật ra thì về bản chất tất cả kiến trúc sinh ra không vì mục đích này. Muốn hệ thống chạy nhanh hơn thì chúng ta đi tối ưu hệ thống, điều chỉnh các I/O xuống DB/disk, shard/replica DB, dùng caching hợp lý, load balancing có đúng chưa... Microservices dù giúp hệ thống chia nhỏ và phân tán nhưng nếu bạn không thực hiện những điều chỉnh trên thì kết quả không khác biệt mấy, hệ thống vẫn chậm, thậm chí chậm hơn do tốn thêm thời gian remote call đến các service nhỏ. Thay vì chuyển đổi lên Microservice ngay, hãy tìm hiểu cụ thể cái gì đang làm chậm hệ thống của bạn! Theo kinh nghiệm của mình, các hệ thống dưới 100K CCU vẫn hoạt động tốt đến rất tốt, ngay cả khi họ không dùng Microservices. Tuy nhiên thực tế vẫn cần phải Monitor cụ thể để hiểu rõ hệ thống hơn. Cứ chia service ra là đượcKhông phải cứ chia service thì sẽ được gọi là Microservices. Khi đến với kiến trúc này bạn sẽ phải tìm hiểu thêm một mớ thứ đi kèm nữa: monitoring, sidecar, service mesh, service discovery, các công cụ deploy và scaling,... Dù những đồ chơi này không nhất thiết phải có, nhưng chúng lại là những thành phần then chốt giúp hệ thống bạn hoạt động ổn định. Microservices loại bỏ các mối lệ thuộc trong hệ thống nhưng lại thêm vào rất nhiều rắc rối khác. Tách service nhưng... xài chung DBNếu làm chuẩn Microservices, bạn sẽ chia tác cả phần code và phần DB. Tức là mỗi service chỉ được sử dụng DB của riêng nó mà thôi. VD service Account thì dùng table accounts, service Product thì dùng table products. Phần này nghe đơn giản nhưng không hề dễ chịu chút nào đâu. Vì bạn sẽ phải đối mặt với các vấn đề sau:
Thường các hệ thống legacy (lâu đời) thì các developer đã quen với việc phó thác những phần khó nhất xuống DB rồi. Từ bỏ chúng là một quyết định không hề dễ dàng. Nó buộc các developer phải thay đổi từ mindset đến cách tổ chức lại dữ liệu cho phù hợp. Đây là lý do nhiều tổ chức sử dụng Microservice với xì-tai chung DB. Việc này không mang lại lợi ích gì cả, họ gọi nó là Microservice nhưng thực tế là không. Không có vị trí DevOps (hoặc hiểu sai về DevOps)Để giải quyết các vấn đề từ Microservices, bạn nên để việc này cho các chuyên gia. Họ chính là những kỹ sư chuyên trách xử lý từ giải pháp hệ thống cho tới deploy và điều hành (Operate) các công cụ trong Microservices. Một sai lầm thường thấy là rất nhiều nơi sử dụng DevOps ở giai đoạn từ Deploy trở đi. Nếu chỉ deploy và quản trị hệ thống thì họ giống như một sysadmin ngày xưa hơn. DevOps nên được tham gia vào ngay từ đầu, họ tham gia vào khâu quyết định lựa chọn các thành phần hệ thống. Hơn ai hết, họ rất hiểu ưu và nhược của các thành phần này, cũng như thực hiện các đo đạc trước khi đưa vào triển khai. DevOps có thể biết code bình thường, nhưng không nhiều, cũng không bắt buộc. Đó là lý do tại sao biểu tượng DevOps là hình vô cực này: DevOps nên tham gia từ đầuChiến lược chuyển đổi hệ thống Monolith lên MicroservicesSau cùng, nếu bạn vẫn muốn chuyển đổi hệ thống từ Monolith lên Microservice, bạn có thể tham khảo một cách tổng quát của mình như sau: Giả sử bạn có một hệ thống monolith khá lớn và đang cần chuyển đổi. Lời khuyên là ở thời điểm đầu mới chuyển đổi bạn không nên tách service quá nhỏ.
Về cơ bản là như vậy, trên thực tế sẽ bạn chỉ mới bước nửa người vào cánh của Microservices thôi. Bởi vì sẽ còn khá nhiều thứ cần xử lý tiếp theo:
Các bạn có thể xem thêm seri chia sẻ về quá trình các bạn developer của đối tác mình nghiên cứu và đưa Microservices vào sản phẩm của họ tại đây: Microsevices #2 Triển khai microservices tinh gọn để bắt đầu dễ dàng hơn - EGANY Blogs Chào mọi người ?, tiếp nối phần trước Microsevices #1 Sự lựa chọn, trong bài viết này mình xin chia sẻ về việc... EGANY BlogsThuan Nguyen Và sau đây là phần quảng cáo!!Nếu bạn quan tâm backend tải cao, mình gợi ý khoá học: Xây dựng backend tải cao với Golang. Hiện mình là mentor chính của khoá. Dù khoá học nội dung chính là Golang và REST API, nhưng trong khoá mình có chia sẻ các kinh nghiệm về hệ thống microservices và tư vấn nếu các bạn cần. Khoá học Golang Food Delivery Backend - 200Lab Education Khoá học Golang xây dựng hệ thống backend tải cao thông qua dự án thực tế Food Delivery. Đạt 01 năm kinh nghiệm Golang sau 16 buổi, hỗ trợ xin việc, update CV. 200Lab Education Chia sẻ slide: 500K CCU với MicroservicesVào cuối năm 2018, mình có vinh dự đại diện cho Sendo (khi ấy mình còn là Solution Architect) đi thuyết trình về hệ thống Microservices ở sự kiện Gopher Conf Viet Nam 2018. Slide gồm 52 trang có giới thiệu các stack và Sendo năm ấy đã đưa vào sử dụng và rất thành công tới ngày nay. Link download bên dưới: |