Tôi đã muốn viết một bài về chủ đề kiến trúc microservice từ lâu, nhưng có hai điều cứ ngăn cản tôi - càng đi sâu vào chủ đề này, tôi càng thấy rằng những gì tôi biết là hiển nhiên và những gì tôi không biết' biết cần phải nghiên cứu và nghiên cứu. Mặt khác, tôi nghĩ rằng đã có điều gì đó để thảo luận giữa đông đảo khán giả. Vì vậy, ý kiến thay thế đều được chào đón.
Định luật Conway và mối quan hệ giữa doanh nghiệp, tổ chức và hệ thống thông tin
Một lần nữa tôi xin phép mình trích dẫn:
“Bất kỳ tổ chức nào thiết kế một hệ thống (theo nghĩa rộng) sẽ nhận được một thiết kế có cấu trúc sao chép cấu trúc của các nhóm trong tổ chức đó.”
— Melvyn Conway, 1967
Theo tôi, luật này có nhiều khả năng liên quan đến tính khả thi của việc tổ chức doanh nghiệp hơn là liên quan trực tiếp đến hệ thống thông tin. Hãy để tôi giải thích bằng một ví dụ. Giả sử chúng ta có một cơ hội kinh doanh khá ổn định với vòng đời dài đến mức việc tổ chức một doanh nghiệp là hợp lý (đây không phải là lỗi đánh máy, nhưng tôi thực sự thích thuật ngữ này mà tôi đã đánh cắp). sẽ tương ứng về mặt tổ chức và quy trình với hoạt động kinh doanh này.
Định hướng kinh doanh hệ thống thông tin
Hãy để tôi giải thích bằng một ví dụ. Giả sử có một cơ hội kinh doanh để tổ chức kinh doanh bán bánh pizza. Ở phiên bản V1 (hãy gọi nó là thông tin trước), công ty là một tiệm bánh pizza, một máy tính tiền và một dịch vụ giao hàng. Phiên bản này tồn tại lâu dài trong điều kiện ít biến đổi môi trường. Sau đó, phiên bản 2 ra đời để thay thế nó - tiên tiến hơn và có thể sử dụng hệ thống thông tin làm cốt lõi cho hoạt động kinh doanh với kiến trúc nguyên khối. Và ở đây, theo tôi, đơn giản là có một sự bất công khủng khiếp liên quan đến những tảng đá nguyên khối - kiến trúc được cho là nguyên khối không tương ứng với mô hình kinh doanh miền. Đúng, nếu đúng như vậy thì hệ thống sẽ không thể hoạt động được - mâu thuẫn với định luật và lẽ thường của Conway. Không, kiến trúc nguyên khối hoàn toàn phù hợp với mô hình kinh doanh ở giai đoạn phát triển kinh doanh này - tất nhiên, ý tôi là giai đoạn mà hệ thống đã được tạo và đưa vào hoạt động. Có một thực tế tuyệt vời là bất kể cách tiếp cận kiến trúc nào, cả kiến trúc hướng dịch vụ phiên bản 3 và kiến trúc microservices phiên bản N đều sẽ hoạt động tốt như nhau. Điều đáng chú ý là gì?
Mọi thứ đều trôi chảy, mọi thứ đều thay đổi hay microservice là một phương tiện để chống lại sự phức tạp?
Trước khi tiếp tục, chúng ta hãy xem xét một số quan niệm sai lầm về kiến trúc microservice.
Những người ủng hộ việc sử dụng phương pháp tiếp cận microservice thường lập luận rằng việc chia một khối nguyên khối thành microservice sẽ đơn giản hóa phương pháp phát triển bằng cách giảm cơ sở mã của từng dịch vụ riêng lẻ. Theo tôi, tuyên bố này là hoàn toàn vô nghĩa. Nghiêm túc mà nói, sự tương tác rõ ràng trong một mã nguyên khối và đồng nhất có vẻ phức tạp? Nếu điều này thực sự xảy ra thì ban đầu tất cả các dự án sẽ được xây dựng dưới dạng vi dịch vụ, trong khi thực tế cho thấy rằng việc di chuyển từ nguyên khối sang vi dịch vụ là phổ biến hơn nhiều. Sự phức tạp không biến mất; nó chỉ đơn giản chuyển từ các mô-đun riêng lẻ sang các giao diện (có thể là bus dữ liệu, RPC, API và các giao thức khác) và hệ thống điều phối. Và điều này thật khó khăn!
Ưu điểm của việc sử dụng ngăn xếp không đồng nhất cũng còn nhiều nghi vấn. Tôi sẽ không tranh luận rằng điều này cũng có thể xảy ra, nhưng trên thực tế nó hiếm khi xảy ra (Nhìn về phía trước - điều này sẽ xảy ra - nhưng đúng hơn là một hệ quả hơn là một lợi thế).
Vòng đời sản phẩm và vòng đời dịch vụ
Hãy nhìn lại sơ đồ trên. Không phải ngẫu nhiên mà tôi ghi nhận vòng đời ngày càng giảm của một phiên bản riêng biệt của một doanh nghiệp - trong điều kiện hiện đại, chính việc tăng tốc chuyển đổi giữa các phiên bản của một doanh nghiệp là yếu tố quyết định sự thành công của nó. Sự thành công của một sản phẩm được quyết định bởi tốc độ thử nghiệm các giả thuyết kinh doanh trong đó. Và đây, theo tôi, là lợi thế chính của kiến trúc microservice. Nhưng hãy đi theo thứ tự.
Hãy chuyển sang giai đoạn tiếp theo trong quá trình phát triển của hệ thống thông tin - tới kiến trúc hướng dịch vụ của SOA. Vì vậy, tại một số điểm nhất định, chúng tôi đã nhấn mạnh trong sản phẩm của mình dịch vụ lâu dài - tồn tại lâu dài theo nghĩa là khi di chuyển giữa các phiên bản của một sản phẩm, có khả năng vòng đời của dịch vụ sẽ dài hơn vòng đời của phiên bản tiếp theo của sản phẩm. Sẽ là hợp lý nếu không thay đổi chúng chút nào - chúng tôi Điều quan trọng là tốc độ chuyển sang phiên bản tiếp theo. Nhưng than ôi, chúng tôi buộc phải thực hiện những thay đổi liên tục đối với các dịch vụ - và ở đây mọi thứ đều phù hợp với chúng tôi, các phương pháp thực hành DevOps, việc đóng gói, v.v. - mọi thứ xuất hiện trong đầu chúng tôi. Nhưng đây vẫn không phải là microservice!
Microservices như một phương tiện để chống lại sự phức tạp... quản lý cấu hình
Và ở đây, cuối cùng chúng ta cũng có thể chuyển sang vai trò xác định của microservice - đây là một phương pháp giúp đơn giản hóa việc quản lý cấu hình sản phẩm. Chi tiết hơn, chức năng của từng microservice mô tả chính xác chức năng kinh doanh bên trong sản phẩm theo mô hình miền - và đây là những thứ không tồn tại trong phiên bản ngắn hạn mà tồn tại trong cơ hội kinh doanh lâu dài. Và quá trình chuyển đổi sang phiên bản tiếp theo của sản phẩm diễn ra mà không được chú ý theo đúng nghĩa đen - bạn thay đổi/thêm một dịch vụ vi mô và có lẽ chỉ là sơ đồ tương tác của chúng, và đột nhiên bạn thấy mình ở tương lai, bỏ lại phía sau những đối thủ cạnh tranh đang khóc lóc tiếp tục nhảy giữa các phiên bản của khối nguyên khối của chúng. Bây giờ hãy tưởng tượng rằng có một khối lượng khá lớn các dịch vụ vi mô với các giao diện và khả năng kinh doanh được xác định trước. Và bạn đến và xây dựng cấu trúc sản phẩm của mình từ các vi dịch vụ làm sẵn - chẳng hạn chỉ bằng cách vẽ sơ đồ. Xin chúc mừng - bạn đã có một nền tảng - và bây giờ bạn có thể thu hút hoạt động kinh doanh cho chính mình. Giấc mơ Giấc mơ.
Những phát hiện
- Kiến trúc của hệ thống phải được xác định bởi vòng đời của các thành phần của nó. Nếu một thành phần tồn tại trong một phiên bản sản phẩm thì việc tăng độ phức tạp của hệ thống bằng cách sử dụng phương pháp vi dịch vụ sẽ chẳng ích gì.
- Kiến trúc microservice phải dựa trên mô hình miền - vì cơ hội kinh doanh là miền tồn tại lâu nhất
- Thực tiễn phân phối (thực tiễn DevOps) và điều phối là một trong những điều quan trọng nhất đối với kiến trúc vi dịch vụ - vì lý do tốc độ thay đổi các thành phần tăng lên đặt ra yêu cầu ngày càng cao về tốc độ và chất lượng phân phối
Nguồn: www.habr.com