Trong bài viết này, Sunteco sẽ giải thích một số kiến thức cơ bản về kiến trúc hướng dịch vụ (SOA) và vi dịch vụ (Micro-services). Kế tiếp, Sunteco sẽ đưa ra những điểm khác biệt chính trong cả hai kiến trúc và xem phương pháp nào sẽ phù hợp nhất với trường hợp ứng dụng trong doanh nghiệp hiện có của bạn.
Nếu doanh nghiệp của bạn đang làm việc trong lĩnh vực CNTT hoặc điện toán đám mây, có lẽ bạn đã biết rõ về cuộc tranh luận về kiến trúc hướng dịch vụ (SOA) so với vi dịch vụ (Micro-services) này, xét cho cùng, ngày nay mọi người đang nói về microservice và các ứng dụng linh hoạt đáp ứng được nhiều trong thực tiễn.
Nhìn chung, cả hai cách tiếp cận có thể được định nghĩa rất giống nhau, và theo một số cách, chúng giống nhau vì cả hai đều liên quan đến môi trường đám mây hoặc đám mây lai (hybrid cloud) để phát triển và triển khai ứng dụng linh hoạt, đồng thời cả hai đều có thể mở rộng quy mô để đáp ứng nhu cầu vận hành và tốc độ của dữ liệu lớn. Cả hai đều chia các ứng dụng lớn, phức tạp thành các thành phần nhỏ, linh hoạt, dễ làm việc hơn. Và cả hai đều khác với kiến trúc nguyên khối, truyền thống ở chỗ mọi dịch vụ đều có trách nhiệm riêng.
Tuy nhiên, ngay cả với những điểm tương đồng chính này, việc xem xét kỹ hơn hai cách tiếp cận sẽ cho thấy những khác biệt quan trọng. Hãy cùng Sunteco xem hết bài viết này để có cái nhìn trực quan hơn về cả hai kiên trúc này. Trước tiên, để hiểu và có cái nhìn chi tiết về kiến trúc Micro-service thì chúng ta nên bắt đầu với SOA, vậy SOA là gì và SOA hoạt động như thế nào?
Khái niệm SOA là gì?
SOA (Service-Oriented Architecture) hay thường được hiểu chính là kiến trúc hướng dịch vụ và là một mẫu kiến trúc sắp xếp phân tách ứng dụng lớn thành các dịch vụ (service). SOA là cấp độ cao hơn của phát triển ứng dụng thường dùng trong quy trình nghiệp vụ và giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật. Cùng so sánh việc trước và sau khi sử dụng SOA sẽ như thế nào bằng hình minh hoạ bên dưới:
Kiến trúc SOA trước và sau khi áp dụng. Nguồn: misbymarioschenk
Cách thức hoạt động của kiến trúc SOA
Mục tiêu của SOA là cho phép các đội nhóm phát triển và triển khai các thành phần của ứng dụng nhanh hơn, giảm phụ thuộc và chờ đợi nhau, linh hoạt trong vận hành và thay đổi – bổ sung dịch vụ.
- Loosely coupled: giảm sự ràng buộc lẫn nhau giữa các thành phần trong ứng dụng, từ quan hệ đan xen giữa các chức năng gọi nhau, chiếm số lượng đến hàng nghìn hàng vạn trong ứng dụng, chuyển sang quan hệ giữa các dịch vụ biệt lập có quan hệ ít phụ thuộc nhau hơn
- Fine-grained: nghiệp vụ của mỗi dịch vụ là độc lập và phạm vi rõ ràng.
- Giao tiếp: giữa các dịch vụ là đơn giản, dễ quản lý và mở rộng thêm dịch vụ mới mà không làm thay đổi phương thức giao tiếp
SOA và Micro-services khác biệt thế nào?
Điểm khác nhau đầu tiên giữa SOA và Micro-services chính là phạm vi áp dụng. Trong khi SOA thường áp dụng đối với phạm vi các doanh nghiệp nơi các ứng dụng giao tiếp với nhau ESB, thì microservice thường sẽ hướng đến việc phát triển các ứng dụng nơi mà giao tiếp giữa các thành phần trong một ứng dụng.
Khác biệt giữa hai hệ thống kiến trúc SOA và kiến trúc Microservices. Nguồn: Up9
Kế đến, Micro-service là sự phát triển tiếp của SOA theo hướng tăng sự độc lập giữa các dịch vụ hơn nữa. Qui mô dịch vụ nhỏ đến mức “micro”, nghĩa là chỉ giải quyết 1 nghiệp vụ cụ thể thay vì 1 nhóm nghiệp vụ kết hợp. Bên cạnh đó, nếu xét về tính loosely coupled, trong khi đó SOA phần dữ liệu vẫn có thể được chia sẻ giữa các dịch vụ, thì micro-service ưu tiên việc độc lập cả về dữ liệu. Bao gồm data store và database.
Điểm khác biệt kế tiếp chính là về sự giao tiếp, thay vì sử dụng các nền tảng quy mô lớn như Enterprise Service Bus, thì micro-service sử dụng các phương thức đơn giản hơn như Restful API hoặc qua Message Bus.
Cuối cùng, do đi theo hướng chia nhỏ hơn, độc lập các dịch vụ hơn như vậy dẫn đến hệ thống có nhiều dịch vụ hơn, phức tạp hơn, đòi hỏi công cụ, qui trình phù hợp cho việc phối hợp giữa phát triển và vận hành (DevOps) để thực sự đáp ứng được tính Continuous Delivery cũng như khả năng mở rộng cao vượt trội hơn so với SOA. Như vậy, phần công cụ, qui trình DevOps là nội dung không thể thiếu trong xây dựng micro-service.
Kiến trúc Micro-services là gì?
Micro-service là một concept, là tư tưởng thiết kế vì vậy không có một định nghĩa duy nhất về micro-service hay những yêu cầu tiêu chuẩn riêng phải đáp ứng. Bên cạnh đó, kiến trúc micro-service ra đời trong bối cảnh các công nghệ hỗ trợ triển khai, giao tiếp cũng như quản lý các tiến trình dịch vụ đã được ra đời và được hoàn thiện.
Kiến trúc micro-services. Nguồn: duplocloud
- Container: giúp isolate dịch vụ trong 1 môi trưởng run-time độc lập không còn phụ thuộc, chia sẻ chung hệ điều hành, các dependency và môi trường thực thi trên cùng 1 máy với các dịch vụ khác.
- Container Orchestrator: ví dụ Kubernetes, Docker Swarm vv…: cho phép điều phối, cập nhật, triển khai và scale container nhanh chóng, dễ dàng trên những server khác nhau.
- Giao tiếp point-to-point: các phương thức giao tiếp qua Web API được hoàn thiện, từ SOAP lên RESTful API.
- Giao tiếp bất đồng bộ: các nền tảng Message Broker như RabitMQ, Kafka.
Đặc điểm hệ thống áp dụng kiến trúc microservices
Dưới đây là những đặc điểm thực tế về một hệ thống đã áp dụng mô hình Micro-service thành công, gồm các yếu tố điển hình dưới đây:
- Có nhiều hơn 1 dịch vụ giao tiếp với nhau để thực hiện nghiệp vụ. Mỗi dịch vụ này nằm trên 1 tiến trình (process) độc lập.
- Các dịch vụ đó thực hiện 1 nghiệp vụ cụ thể thay vì không có nhiệm vụ rõ ràng, buộc phải liên kết với dịch vụ khác mới thực hiện được nghiệp vụ, hay thực hiện quá nhiều nghiệp vụ khác nhau trong 1 dịch vụ.
- Việc sử dụng công nghệ, ngôn ngữ, cách lưu trữ dữ liệu là độc lập lẫn nhau giữa các dịch vụ. Cho phép việc thay đổi, triển khai dịch vụ được diễn ra độc lập. Tuy vậy chúng thường được liên kết với nhau trong 1 network chung.
- Do tính độc lập, có nhiều dịch vụ vận hành chỉ quan tâm đến dữ liệu nhận vào mà không quan tâm dữ liệu đó đến từ dịch vụ nào, và chỉ quan tâm đến dữ liệu mà nó cần trả về mà không cần quan tâm dịch vụ nào sẽ tiếp nhận nó, nên hình thức giao tiếp bằng bản tin bất đồng bộ thường được áp dụng hơn là sử dụng hình thức giao tiếp point-to-point trực tiếp giữa các dịch vụ.
Ưu điểm của kiến trúc microservices
Từ nhiều năm nay, micro-service đã trở thành xu thế trong phát triển phần mềm. Thật ngữ micro-services cũng không quá xa lạ đối với các nhà phát triển ứng dụng nói chung, và giới công nghệ nói riêng. Tuy nhiên, việc hiểu sâu lợi ích từ việc áp dụng công nghệ micro-services lại không được nhiều người biết đến. Dưới đây là ba ưu điểm thực tế mà micro-services đã và đang giúp các doanh nghiệp vượt qua các khó khăn gặp phải.
Ưu điểm 1: Tăng khả năng linh hoạt
Tăng khả năng linh hoạt trong các lựa chọn công nghệ cho dịch vụ mà team sẽ phát triển. Không còn bị lệ thuộc vào công nghệ của các thành phần đã được xây dựng trước đó như trong kiến trúc Monolith.
Ví dụ: một sàn thương mại điện tử có thể được phát triển dựa trên kiến trúc micro-service hoặc monolith. Nếu dựa trên monolith, các thành phần như tìm kiếm hàng hoá, đặt hàng, vận chuyển hàng hoá… sẽ được xây dựng trong cùng một chương trình viết bằng một ngôn ngữ, cụ thể, Java và sử dụng một database chung cùng một engine chung (ví dụ như Oracle). Khi doanh nghiệp cần phát triển thêm các dịch vụ để tính giá bán theo các hình thức giảm giá khác nhau, doanh nghiệp bắt buộc phải tiếp tục viết thêm các lớp mã Java mới cho việc đó nằm trên cùng chương trình hiện tại, truy cập vào cùng cơ sở dữ liệu Oracle hiện tại. Trong khi nếu các nhà phát triển thực hiện hệ thống theo kiểu micro-service, thì việc định nghĩa ra một micro-service chuyên cho việc tính giá bán được phát triển bằng bất cứ ngôn ngữ/web framework nào nhà phát triển thành thạo, như .NET, NodeJS, Ruby on Rails hay Golang, sử dụng các database với engine phù hợp hơn với nhu cầu của dịch vụ đó, MySQL thay vì Oracle cho các quy mô dữ liệu nhỏ.
Ưu điểm 2: Khả năng mở rộng khi vận hành
Khả năng mở rộng khi vận hành là một trong những ưu điểm quan trọng nhất của micro-service. Khi được tách nhỏ thành các dịch vụ nhỏ có nghiệp vụ độc lập, tài nguyên CPU, RAM có thể được phân bổ tối ưu hơn, giảm thiểu phân bổ ở các dịch vụ có nhu cầu thấp, và tối đa phân bổ ở các dịch vụ có nhu cầu cao. Các dịch vụ micro-service không nhất thiết phải đặt ở trong một máy chủ mà có thể đặt ở nhiều máy chủ khác nhau. Giảm tải cho việc tính toán trên một máy chủ.
Nhờ sự hoàn thiện các công nghệ trên, micro-service đang ngày càng trở nên phổ biến và được áp dụng rộng rãi hơn và đã trở thành xu thế trong phát triển phần mềm. Đặc biệt; các dịch vụ khi được đặt trong các bộ chứa (Container), nếu được áp dụng các công cụ điều phối container phù hợp, sẽ dễ dàng được nhân bản (scale) để tăng khả năng xử lý song song, đáp ứng nhu cầu của các dịch vụ có sự biến thiên mức tiêu thụ trong quá trình vận hành. Đặc điểm này rất khó có được ở mô hình monolith; toàn bộ hệ thống đặt trong một máy chủ. Nếu cần nhân bản, sẽ phải nhân bản toàn bộ máy chủ thay vì chỉ những dịch vụ micro-service thật sự có nhu cầu. Đó là một quá trình vừa lãng phí tài nguyên do phải duy trì nhiều máy chủ, vừa tốn nhiều thời gian đáp ứng do việc khởi động máy chủ và dịch vụ trên đó luôn tốn nhiều thời gian hơn khởi động một dịch vụ trên máy chủ đã có sẵn. Micro-service có rất nhiều ưu điểm, nhưng chỉ riêng ưu điểm này đã đem lại hai lợi ích quan trọng nhất quan trọng nhất của mọi hệ thống khiến mọi team phát triển đều phải cân nhắc: Khả năng đáp ứng nhu cầu và độ trễ tốt hơn và Chi phí vận hành thấp hơn.
Ưu điểm 3: Rút ngắn thời gian phát triển
Rút ngắn thời gian phát triển là giai đoạn sản phẩm mới hình thành là lúc “hạnh phúc” nhất của mọi doanh nghiệp vì tính năng được ra đời liên tục. Tuy nhiên khi hệ thống lớn lên, mỗi thay đổi sẽ cần phải được cân nhắc tính ảnh hưởng với các thành phần sẵn có, và đòi hỏi người phát triển phải hiểu được tương đối sâu về hệ thống đang có để “lắp” các thành phần mới vào đúng chỗ. Điều đó làm chậm lại quá trình phát triển và không hoàn toàn đảm bảo sẽ không tạo ra vấn đề mới.
Tuy nhiên, khi hệ thống càng lớn lên, thì tốc độ phát triển mới sẽ càng bị chậm lại và điều này không thể tránh khỏi ở các hệ thống đang áp dụng hệ thống kiến trúc monolith, nơi các thành phần ràng buộc chặt chẽ và ảnh hưởng lớn lẫn nhau. Khi chuyển sang sử dụng hệ thống micro-service và thực hiện đúng các concept (concept quan trọng nhất: đảm bảo micro-service có sự độc lập về nghiệp vụ, ít ràng buộc với các service khác), các nhà phát triển sẽ được hỗ trợ đầy đủ về công nghệ-công cụ và việc bổ sung các tính năng mới có thể được thực hiện bởi các team độc lập và không cần quá quan tâm về sự tồn tại của các micro-service đã có trước đây. Các tính năng bổ sung có thể được triển khai độc lập không ràng buộc trong một code base chung. Điều này cho phép tính “Continous Integration – Continuous Deployment” (CI-CD), ứng dụng được liên tục phát triển và triển khai ở tốc độ cao.
Vậy nên lựa chọn SOA hay Micro-services?
Để lựa chọn công nghệ nào sẽ phù hợp thì phải xem xét đến quy mô và đa dạng từ môi trường ứng dụng của doanh nghiệp. Cả SOA và Micro-services đều có thể sử dụng tự động hóa để tăng tốc quy trình kinh doanh. Các môi trường lớn hơn, đa dạng hơn có xu hướng nghiêng về kiến trúc hướng dịch vụ (SOA), hỗ trợ tích hợp giữa các ứng dụng không đồng nhất và các giao thức nhắn tin thông qua một bus dịch vụ doanh nghiệp (ESB). Các môi trường nhỏ hơn, bao gồm các ứng dụng web và di động, không yêu cầu lớp giao tiếp mạnh mẽ như vậy và dễ phát triển hơn bằng kiến trúc Micro-services. Dưới đây là trường hợp sàn thương mại điện tử ứng dụng hệ thống kiến trúc microservices và đã giải quyết được những vấn đề khó khăn trong hệ thống hiện có.
Có rất nhiều cuộc tranh luận như kiến trúc SOA sẽ phức tạp hơn nhiều so với kiến trúc Micro-services, và điều đó hoàn toàn đúng. Tuy nhiên, các cuộc tranh luận còn rất nhiều điều thú vị và vẫn còn mãi kéo dài. Tuy nhiên, từ góc độ kinh doanh, quy mô và phạm vi của ứng dụng mới thực sự là điểm khác biệt quan trọng. Doanh nghiệp nên tìm hiểu và phân tích rõ ràng mục tiêu cũng như mong muốn phát triển ứng dụng để có thể lựa chọn được cho mình kiến trúc và công nghệ phù hợp nhất.