Đưa 'Micro' vào microservice với Raspberry Pi


Trịnh Khả Ngân
4 năm trước
Hữu ích 10 Chia sẻ Viết bình luận 0
Đã xem 3820

Gần đây tôi đã có một vài cuộc nói chuyện về microservice (tại JAX London , JFokusJavaLand , tất cả các hội nghị tuyệt vời). Microservice là một cách thú vị để đối phó với một số sự phức tạp trong một dự án phần mềm không tầm thường bằng cách phân vùng hệ thống và, giống như nhiều lựa chọn công nghệ chúng tôi thực hiện, có sự đánh đổi.

Tôi muốn giải thích những sự đánh đổi này trong các cuộc nói chuyện của tôi bằng cách đảm bảo tất cả chúng đều có trong bản demo của tôi. Đây là - tôi hy vọng - mang tính giáo dục, nhưng nó chắc chắn không tốt cho huyết áp của tôi. Tôi không muốn sao chép nội dung microservice tuyệt vời đã có, nhưng hãy để tôi chia sẻ ba cách học quan trọng nhất cho tôi.

Hệ thống phân tán và lỗi

Microservice thay thế các hệ thống nguyên khối bằng các hệ thống phân tán. Gần như theo định nghĩa, điều này có nghĩa là một vụ nổ của các bộ phận chuyển động. Trong ngữ cảnh demo, khi mọi thứ đang chạy trên một máy tính xách tay, bạn dễ dàng quên rằng kiến ​​trúc microservice thực sự là một hệ thống có rất nhiều thứ khác nhau đang cố gắng giao tiếp với nhau qua một mạng không đáng tin cậy. Ngay cả trong một hệ thống 'thực', với ảo hóa và các thùng chứa, không phải lúc nào cũng rõ ràng có bao nhiêu sự phức tạp liên quan đến hệ thống tổng hợp - miễn là mọi thứ hoạt động tốt. Rốt cuộc, lý do ngụy biện của điện toán phân tán được gọi là ngụy biện là bởi vì chúng là những giả định mà tất cả chúng ta có xu hướng thực hiện.

Tôi quyết định thực sự đưa 'micro' vào 'microservice', vì vậy tôi đã chuẩn bị một hệ thống Raspberry PispcDuinos . WebSphere Liberty rất nhẹ đến nỗi nó có thể dễ dàng chạy trên Pi và nó nhỏ và rẻ đến mức tôi có thể dễ dàng xây dựng một bộ sưu tập máy tính. Tôi gọi nó là 'trung tâm dữ liệu trong túi xách tay.' Bởi vì mỗi máy thực sự là một máy, cấu trúc liên kết rõ ràng hơn:


Sự phức tạp của các kết nối cũng trở nên thực sự rõ ràng (hình ảnh này không được dàn dựng!):


Ngay sau khi bức ảnh này được chụp, tôi đã chuyển sang sử dụng wifi để liên lạc qua mạng, chỉ vì tôi không thể đối phó với cáp ethernet nữa. Có nhiều máy tính nhỏ làm cho bản chất của kiến ​​trúc microservice trở nên hữu hình hơn, nhưng nó cũng khiến cho việc demo trở nên khó khăn hơn rất nhiều. Thành thật mà nói, đây là một điều tốt. Xây dựng một kiến ​​trúc microservice vững chắc có nghĩa là xây dựng trong khả năng chịu thất bại - thử nghiệm một kiến ​​trúc như vậy trên một loạt các máy tính có thể nhúng để đảm bảo dung sai này chắc chắn không bị lãng quên! (Hãy nhớ rằng, bạn đang thay thế các lệnh gọi API trong ứng dụng của mình bằng các cuộc gọi HTTP trong một hệ thống.)

Khám phá dịch vụ

Điều thú vị về một trung tâm dữ liệu trong túi xách là nó khá di động; Tôi đã lấy của tôi trên khắp châu Âu. Để giữ mọi thứ di động, tôi đã sử dụng DHCP, vì vậy mỗi lần tôi di chuyển hệ thống của mình, tất cả các địa chỉ IP đều thay đổi.


Điều này làm cho khám phá dịch vụ quan trọng. Khám phá dịch vụ cho phép microservice nói chuyện với các dịch vụ siêu nhỏ khác mà không cần mã hóa cứng địa chỉ IP hoặc tên máy chủ trước.

Có một vài lý do tại sao địa chỉ IP không đủ tốt. Nếu một hệ thống ngừng hoạt động, sự thay thế của nó sẽ phải có cùng một địa chỉ; mặt khác, tất cả các cuộc gọi đến dịch vụ từ các thành phần khác sẽ không thành công, mặc dù dịch vụ thay thế đã hết. Bởi vì máy tính của tôi sẽ di chuyển giữa các mạng con khác nhau (và các tòa nhà và quốc gia!) Nên chúng thực sự phải sử dụng DHCP và không tương thích với việc có một địa chỉ IP cố định. Nghiêm trọng hơn, nếu chúng tôi muốn mở rộng quy mô dịch vụ, chúng tôi không có cách phân phối lưu lượng truy cập trên các phiên bản dịch vụ nếu địa chỉ IP điểm cuối bị mã hóa cứng.


Chúng tôi có thể nhận được một số cách nếu chúng tôi kiểm soát tốt sổ đăng ký DNS của mình và bộ cân bằng tải cũng có ích - nhưng tại thời điểm này, chúng tôi đang đi đến một giải pháp khám phá dịch vụ.

Khám phá dịch vụ là một công nghệ mới nổi, và có một số giải pháp phổ biến. Hiện tại, Eureka , Apache Zookeeper + Curator , Kubernetes , vân vânlãnh sự đều phổ biến. Consul by Hashicorp đang ngày càng phổ biến và có một số tính năng hấp dẫn, bao gồm hỗ trợ nền tảng rộng và giao diện DNS. Bluemix cũng bao gồm tính năng khám phá dịch vụ betatính năng proxy dịch vụ bổ sung (cũng ở phiên bản beta).

Tôi nhận thấy rằng hầu hết mọi khung khám phá dịch vụ đều chịu trách nhiệm đăng ký dịch vụ với chính ứng dụng đó. Lười biếng, và với năm ứng dụng để quản lý, điều này có vẻ như rất nhiều công việc khó khăn. Máy chủ ứng dụng biết liệu nó có hoạt động hay không (và rõ ràng) và nó biết chính xác những điểm cuối REST đang phơi bày, vậy tại sao không mở rộng nó để xử lý đăng ký dịch vụ?

WebSphere Liberty có khả năng mở rộng thực sự tốt, vì vậy thật dễ dàng để nối vào các sự kiện bắt đầu và dừng cho mỗi ứng dụng tiếp xúc với các điểm cuối JAX-RS. Sau đó, tiện ích mở rộng có thể sử dụng lại quá trình quét chú thích đã được máy chủ thực hiện để tìm ra tên của từng điểm cuối REST và đăng ký dưới dạng dịch vụ. Tôi sử dụng Consul làm đăng ký dịch vụ của mình nhưng nguyên tắc tương tự có thể được sử dụng cho mọi đăng ký. Các mã nguồn cho các plug-in có sẵn trên GitHub. (Cũng như trình bày cách tích hợp Lãnh sự và Tự do, đây là một mẫu hữu ích về cách kết hợp chức năng quét chú thích của Liberty, có tất cả các loại sử dụng.)

Mở rộng ra đám mây

Mặc dù rất thú vị, nhưng trung tâm dữ liệu trong túi xách có lẽ không phải là cấu trúc liên kết thực tế nhất cho hệ thống sản xuất và Raspberry Pis đã quá giỏi trong việc chứng minh các sai lầm điện toán phân tán. Tôi cũng đã triển khai cùng một bộ ứng dụng trên bốn nút Bluemix chạy Liberty.

Tôi đã phải thực hiện một vài thay đổi để thích ứng với môi trường khác nhau trong một đám mây được quản lý. Đặc biệt, khi mọi thứ đang chạy trong một container, địa chỉ IP mà các ứng dụng chạy bên trong container nhìn thấy không giống với phần còn lại của thế giới. Điều này phá vỡ tự khám phá dịch vụ tự đăng ký. Hóa ra đây là một vấn đề phổ biến đối với khám phá dịch vụ trong các container .

Nó cũng xảy ra rằng việc biết địa chỉ IP của máy chủ ít quan trọng hơn trong Bluemix; cả các ứng dụng và nhóm container của Cloud Foundry đều có tuyến đường được đặt tên và có thể được sử dụng để giải quyết dịch vụ. Bluemix cũng đảm nhiệm việc cân bằng tải, do đó một tuyến có thể được phục vụ bởi một số máy chủ. Điều này làm cho khám phá dịch vụ ít cần thiết hơn, nhưng vẫn hữu ích:

  • Tôi vẫn muốn theo dõi có bao nhiêu dịch vụ của tôi đã xuất hiện trên bảng điều khiển của Lãnh sự.
  • Tôi muốn hỗ trợ một môi trường lai với các dịch vụ Raspberry Pis và Bluemix hoạt động cùng nhau, và điều đó chắc chắn cần khám phá dịch vụ. Ví dụ: giao diện người dùng web chạy trên Pi có thể nói chuyện với máy chủ Lãnh sự chạy trên bộ chứa Dock của Bluemix và sử dụng một số dịch vụ chạy trên Pis khác cũng như một số dịch vụ chạy trên Bluemix.
  • Tôi muốn mã chung cho cả cấu trúc liên kết túi xách và đám mây.

Thông thường, cách duy nhất để cho phép một ứng dụng được đóng gói tự đăng ký với một sổ đăng ký dịch vụ là cho nó biết địa chỉ IP hoặc tên máy chủ nào nên sử dụng, thông qua một biến môi trường. Bluemix thực hiện điều này cho chúng tôi, vì vậy tên máy chủ công cộng của một ứng dụng có sẵn trong VCAP_APPLICATIONbiến môi trường. Nó cũng được tiêm vào Liberty server.xmlnhư ${application_uris}, mà thậm chí còn thuận tiện hơn.

Tôi đã thêm một kiểm tra bổ sung vào logic nội quan tên máy chủ của mình để kiểm tra VCAP_APPLICATIONbiến môi trường và phân tích nó, nếu có. (Vì được tích hợp với cơ sở hạ tầng Bluemix, dịch vụ Khám phá Dịch vụ Bluemix đảm nhiệm việc ánh xạ giữa địa chỉ IP riêng và địa chỉ công cộng, do đó, các dịch vụ tự đăng ký sử dụng địa chỉ IP riêng của họ, nhưng được đăng ký quảng cáo bằng cách sử dụng địa chỉ công khai. )

JAX-RS khá tuyệt vời

Điều đầu tiên tôi làm trong bản demo là tái cấu trúc một khối nguyên khối thành microservice. Có rất nhiều điều có thể làm cho điều này thực sự khó khăn: thử nghiệm thay đổi hoàn toàn, đóng gói kém sẽ phải được sắp xếp và đường ống DevOps sẽ là một con thú hoàn toàn mới. Tuy nhiên, có một điều thực sự khá dễ dàng: Tôi đã sử dụng CDI để xử lý giao tiếp giữa các yếu tố khác nhau trong ứng dụng ban đầu của tôi và về cơ bản, đó là sự hoán đổi một đổi một sang sử dụng JAX-RS để xuất bản và sử dụng các dịch vụ RESTful.

JAX-RS là một phần của đặc tả Java EE và dĩ nhiên, được tích hợp sẵn cho Liberty . Nó thực hiện một công việc tuyệt vời là trừu tượng hóa các chi tiết của REST. Mặc dù các dịch vụ của tôi đã sử dụng HTTP và JSON, nhưng không có dịch vụ nào được tiếp xúc với mã của tôi. Để xuất bản, tôi hoàn toàn không phải thay đổi API, chỉ cần trao đổi chú thích CDI cho JAX-RS.

@Produces(MediaType.APPLICATION_JSON)
 @GET


Để tiêu thụ một dịch vụ mất khoảng ba dòng mã:

Client client = ClientBuilder.newClient();
WebTarget target = client.target(“http://catastrophe-cats.mybluemix.net:9080").path(“/rest/cats”);
Set<Cat> cats = target.request(MediaType.APPLICATION_JSON).get(new GenericType<>(Set.class));


Nếu bạn đang tự hỏi về tên - tất cả nội dung internet tốt liên quan đến mèo. Của tôi là một bản demo trực tiếp, và tôi có một số kinh nghiệm về các bản demo trực tiếp, vì vậy tôi đã gọi nó - tất nhiên -  cat-astrophe .

Suy nghĩ cuối cùng

Vì vậy, tôi đã học được gì khi kết thúc cuộc phiêu lưu microservice của mình? Dịch vụ vi mô là công việc khó khăn. Nếu bạn đang nghĩ về microservice, tốt hơn bạn nên nghĩ về cơ sở hạ tầng nào bạn sẽ đưa vào để hỗ trợ khám phá dịch vụ, ngắt mạch, ghi nhật ký và thử nghiệm. Ngành công nghiệp của chúng tôi đang phát triển rất nhanh, vì vậy giải pháp tốt nhất khi bắt đầu hành trình của tôi (như Lãnh sự), không nhất thiết là giải pháp tốt nhất cho đến khi tôi kết thúc (bây giờ chúng tôi có Bluemix Service Discovery ). Oh, và đá mở rộng Liberty. Nhưng chúng ta đã biết điều đó rồi, phải không?

Thẻ từ liên quan:

Bắt đầu với microservice

Hữu ích 10 Chia sẻ Viết bình luận 0
Đã xem 3820