Xin chào, Habr. Hôm nay tôi tiếp tục một loạt ấn phẩm mà tôi đã viết đặc biệt để bắt đầu một luồng mới của khóa học. .
Giới thiệu
Việc lựa chọn phong cách kiến trúc là một trong những quyết định kỹ thuật cơ bản khi xây dựng một hệ thống thông tin. Trong loạt bài viết này, tôi đề xuất phân tích các phong cách kiến trúc phổ biến nhất cho các ứng dụng xây dựng và trả lời câu hỏi khi nào phong cách kiến trúc nào được ưa thích nhất. Trong quá trình trình bày, tôi sẽ cố gắng vẽ ra một chuỗi logic giải thích sự phát triển của các phong cách kiến trúc từ nguyên khối đến microservice.
В chúng tôi đã xử lý khối nguyên khối và đi đến kết luận rằng khối nguyên khối có một số vấn đề: kích thước, khả năng kết nối, triển khai, khả năng mở rộng, độ tin cậy và độ cứng.
Lần này tôi đề xuất nói về khả năng tổ chức một hệ thống như một tập hợp các mô-đun/thư viện (kiến trúc hướng thành phần) hoặc dịch vụ (kiến trúc hướng dịch vụ).
Kiến trúc hướng thành phần
Kiến trúc hướng thành phần bao gồm việc thực thi một hệ thống như một tập hợp các thành phần có thể được sử dụng trong cả các dự án hiện tại và tương lai. Khi chia nhỏ một hệ thống thành các thành phần, những điều sau đây được tính đến: khả năng sử dụng lại, khả năng thay thế, tính độc lập về ngữ cảnh, khả năng mở rộng, tính đóng gói và tính độc lập.
Với việc sử dụng hợp lý các thành phần, vấn đề “quả bóng lớn” (kích thước lớn + khả năng ghép nối cao) đã được giải quyết và bản thân các thành phần có thể vừa là đơn vị lắp ráp (mô-đun, thư viện) vừa là đơn vị triển khai (dịch vụ). Các đơn vị triển khai không phải lúc nào cũng được ánh xạ tới quy trình đang chạy: ví dụ: một ứng dụng web và cơ sở dữ liệu được triển khai cùng nhau.
Thông thường, khối nguyên khối được phát triển dưới dạng một tập hợp các mô-đun. Cách tiếp cận này dẫn đến sự phát triển độc lập, nhưng vẫn còn các vấn đề về mở rộng và triển khai độc lập, khả năng chịu lỗi và tính độc lập khỏi kho công nghệ tổng thể. Đó là lý do tại sao mô-đun này là một thành phần độc lập một phần.
Vấn đề lớn nhất với một khối nguyên khối như vậy là việc phân chia thành các mô-đun hoàn toàn hợp lý và có thể dễ dàng bị các nhà phát triển vi phạm. Một mô-đun lõi có thể xuất hiện, dần dần biến thành bãi rác, biểu đồ phụ thuộc giữa các mô-đun có thể phát triển, v.v. Để tránh những vấn đề như vậy, quá trình phát triển phải được thực hiện bởi một nhóm rất trưởng thành hoặc dưới sự hướng dẫn của một “kiến trúc sư”, người tham gia đánh giá mã toàn thời gian và đánh bại những nhà phát triển vi phạm cấu trúc logic.
Khối nguyên khối “lý tưởng” là một tập hợp các mô-đun được phân tách hợp lý, mỗi mô-đun xem xét cơ sở dữ liệu riêng của nó.
Kiến trúc hướng dịch vụ
Nếu hệ thống được cho là được tổ chức dưới dạng một tập hợp các dịch vụ thì chúng ta đang nói về một kiến trúc hướng dịch vụ. Nguyên tắc của nó là khả năng tương tác ứng dụng lấy người dùng làm trung tâm, tái sử dụng dịch vụ kinh doanh, tính độc lập của ngăn xếp công nghệ và quyền tự chủ (tiến hóa độc lập, khả năng mở rộng và triển khai).
Kiến trúc hướng dịch vụ (SOA = kiến trúc hướng dịch vụ) giải quyết tất cả các vấn đề đã xác định của nguyên khối: chỉ một dịch vụ bị ảnh hưởng khi có thay đổi xảy ra và API được xác định rõ sẽ hỗ trợ đóng gói tốt các thành phần.
Nhưng không phải mọi thứ đều suôn sẻ như vậy: SOA tạo ra những vấn đề mới. Các cuộc gọi từ xa đắt hơn các cuộc gọi cục bộ và việc phân phối lại trách nhiệm giữa các thành phần cũng trở nên đắt hơn đáng kể.
Nhân tiện, khả năng triển khai độc lập là một tính năng rất quan trọng của dịch vụ. Nếu các dịch vụ phải được triển khai cùng nhau hoặc hơn nữa, theo một trình tự nhất định thì hệ thống không thể được coi là hướng dịch vụ. Trong trường hợp này, họ nói về một khối nguyên khối phân tán (được coi là một mô hình chống không chỉ theo quan điểm của SOA mà còn theo quan điểm của kiến trúc microservice).
Kiến trúc hướng dịch vụ được cộng đồng kiến trúc và nhà cung cấp hỗ trợ tốt. Điều này ngụ ý sự hiện diện của nhiều khóa học và chứng chỉ, các mô hình được phát triển tốt. Ví dụ, cái sau bao gồm bus dịch vụ doanh nghiệp nổi tiếng (ESB = bus dịch vụ doanh nghiệp). Đồng thời, ESB là hành trang của các nhà cung cấp; nó không nhất thiết phải được sử dụng trong SOA.
Mức độ phổ biến của kiến trúc hướng dịch vụ đạt đỉnh điểm vào khoảng năm 2008, sau đó nó bắt đầu suy giảm và trở nên nghiêm trọng hơn đáng kể sau sự ra đời của microservice (~ 2015).
Kết luận
Sau khi chúng ta thảo luận về khả năng tổ chức hệ thống thông tin dưới dạng dịch vụ và mô-đun, tôi đề xuất cuối cùng chuyển sang các nguyên tắc của kiến trúc microservice và đặc biệt chú ý đến sự khác biệt giữa kiến trúc microservice và kiến trúc hướng dịch vụ trong phần tiếp theo.
Nguồn: www.habr.com