Xin chào, Habr. Đăng ký cho một luồng khóa học mới hiện đang mở tại OTUS . Trước ngày bắt đầu khóa học, tôi muốn chia sẻ với bạn bài viết gốc của tôi.
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.
Một chút lịch sử
Nếu bạn thử hỏi các nhà phát triển: “Tại sao chúng ta cần microservice?”, bạn sẽ nhận được nhiều câu trả lời khác nhau. Bạn sẽ nghe nói rằng vi dịch vụ cải thiện khả năng mở rộng, làm cho mã dễ hiểu hơn, cải thiện khả năng chịu lỗi và đôi khi bạn sẽ nghe rằng chúng cho phép bạn "làm sạch mã của mình". Hãy nhìn lại lịch sử để hiểu mục đích đằng sau sự xuất hiện của microservice.
Nói tóm lại, microservice theo hiểu biết hiện tại của chúng ta phát sinh như sau: vào năm 2011, James Lewis, khi phân tích công việc của nhiều công ty khác nhau, đã thu hút sự chú ý đến sự xuất hiện của một mẫu “ứng dụng vi mô” mới, giúp tối ưu hóa SOA về mặt đẩy nhanh việc triển khai dịch vụ. Một thời gian sau, vào năm 2012, tại hội nghị thượng đỉnh về kiến trúc, mô hình này đã được đổi tên thành microservice. Vì vậy, mục tiêu ban đầu của việc giới thiệu microservice là cải thiện những vấn đề khét tiếng thời gian để thị trường.
Dịch vụ vi mô đã trở thành làn sóng cường điệu vào năm 2015. Theo một số nghiên cứu, không một hội nghị nào được hoàn thành nếu không có báo cáo về chủ đề microservice. Hơn nữa, một số hội nghị được dành riêng cho microservice. Ngày nay, nhiều dự án bắt đầu sử dụng phong cách kiến trúc này và nếu dự án chứa rất nhiều mã kế thừa thì việc chuyển đổi sang microservices có thể đang được thực hiện tích cực.
Bất chấp tất cả những điều trên, một số lượng khá nhỏ các nhà phát triển vẫn có thể định nghĩa được khái niệm “microservice”. Nhưng chúng ta sẽ nói về điều này sau...
nguyên khối
Phong cách kiến trúc tương phản với microservice là nguyên khối (hoặc tất cả trong một). Có lẽ không có ý nghĩa gì khi nói nguyên khối là gì, vì vậy tôi sẽ liệt kê ngay những nhược điểm của phong cách kiến trúc này, điều này đã khởi đầu cho sự phát triển hơn nữa của các phong cách kiến trúc: 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. Dưới đây tôi đề xuất xem xét từng thiếu sót một cách riêng biệt.
kích thước
Khối đá nguyên khối rất lớn. Và nó thường giao tiếp với một cơ sở dữ liệu rất lớn. Ứng dụng trở nên quá lớn để một nhà phát triển có thể hiểu được. Chỉ những người đã dành nhiều thời gian làm việc với mã này mới có thể làm việc tốt với đá nguyên khối, trong khi những người mới bắt đầu sẽ mất nhiều thời gian để tìm ra nguyên khối và không có gì đảm bảo rằng họ sẽ tìm ra nó. Thông thường, khi làm việc với monolith, luôn có một số tiền bối “có điều kiện” biết ít nhiều về monolith và đánh bại các nhà phát triển mới khác trong vòng một năm rưỡi. Đương nhiên, như vậy có điều kiện tiền bối chính là một điểm thất bại, hắn rời đi có thể dẫn đến nguyên khối cái chết.
Sự kết nối
Khối đá nguyên khối là một “quả bóng bùn lớn”, những thay đổi trong đó có thể dẫn đến những hậu quả khó lường. Bằng cách thực hiện các thay đổi ở một nơi, bạn có thể làm hỏng tảng đá nguyên khối ở một nơi khác (“bạn gãi tai, *@ rơi ra”). Điều này là do thực tế là các thành phần trong khối nguyên khối có mối quan hệ rất phức tạp và quan trọng nhất là không rõ ràng.
Triển khai
Triển khai một khối nguyên khối, do mối quan hệ phức tạp giữa các thành phần của nó, là một quá trình lâu dài với nghi thức riêng. Một nghi lễ như vậy thường không được chuẩn hóa hoàn toàn và được truyền lại “bằng miệng”.
Khả năng mở rộng
Các mô-đun nguyên khối có thể có nhu cầu tài nguyên xung đột nhau, đòi hỏi phải thỏa hiệp về mặt phần cứng. Hãy tưởng tượng rằng bạn có một khối nguyên khối bao gồm các dịch vụ A và B. Dịch vụ A yêu cầu về kích thước ổ cứng và dịch vụ B yêu cầu về RAM. Trong trường hợp này, máy được cài đặt khối nguyên khối phải hỗ trợ các yêu cầu của cả hai dịch vụ hoặc bạn sẽ phải vô hiệu hóa một trong các dịch vụ theo cách thủ công, giả tạo.
Một ví dụ khác (cổ điển hơn): dịch vụ A phổ biến hơn nhiều so với dịch vụ B, vì vậy bạn muốn có 100 dịch vụ A và 10 dịch vụ B. Một lần nữa, có hai lựa chọn: hoặc chúng tôi triển khai 100 dịch vụ nguyên khối chính thức hoặc trên một số dịch vụ sau đó dịch vụ B sẽ phải bị vô hiệu hóa bằng tay.
Độ tin cậy
Vì tất cả các dịch vụ được đặt cùng nhau nên nếu khối nguyên khối rơi xuống thì tất cả các dịch vụ sẽ rơi cùng một lúc. Trên thực tế, điều này có thể không quá tệ, ít nhất sẽ không có lỗi cục bộ nào trong hệ thống phân tán, nhưng mặt khác, do lỗi trong chức năng được 0.001% người dùng sử dụng, bạn có thể mất tất cả người dùng. của hệ thống của bạn.
Quán tính
Do kích thước nguyên khối nên rất khó để chuyển sang công nghệ mới. Kết quả là, việc giữ chân người cấp cao đó là một nhiệm vụ riêng biệt. Nhóm công nghệ được chọn khi bắt đầu dự án có thể trở thành khối cản trở sự phát triển của sản phẩm.
Kết luận
Lần tới chúng ta sẽ nói về cách mọi người đã cố gắng giải quyết những vấn đề này bằng cách chuyển sang các thành phần và SOA.
Đọc thêm:
Nguồn: www.habr.com