Xin chào! Tên tôi là Vadim Madison, tôi lãnh đạo việc phát triển Nền tảng hệ thống Avito. Người ta đã hơn một lần nói về việc chúng tôi trong công ty đang chuyển từ kiến trúc nguyên khối sang kiến trúc vi dịch vụ. Đã đến lúc chia sẻ cách chúng tôi chuyển đổi cơ sở hạ tầng để tận dụng tối đa các dịch vụ vi mô và giúp chúng tôi không bị lạc vào chúng. Ở đây PaaS giúp chúng tôi như thế nào, cách chúng tôi đơn giản hóa việc triển khai và giảm việc tạo vi dịch vụ chỉ bằng một cú nhấp chuột - hãy đọc tiếp. Không phải mọi thứ tôi viết dưới đây đều được triển khai đầy đủ trong Avito, một số trong đó là cách chúng tôi phát triển nền tảng của mình.
(Và ở cuối bài viết này, tôi sẽ nói về cơ hội được tham dự buổi hội thảo kéo dài ba ngày từ chuyên gia kiến trúc microservice Chris Richardson).
Chúng tôi đến với microservice như thế nào
Avito là một trong những trang rao vặt lớn nhất thế giới, mỗi ngày có hơn 15 triệu quảng cáo mới được đăng trên đó. Phần phụ trợ của chúng tôi chấp nhận hơn 20 nghìn yêu cầu mỗi giây. Chúng tôi hiện có hàng trăm microservice.
Chúng tôi đã xây dựng kiến trúc microservice được vài năm nay. Chính xác như thế nào - chi tiết về đồng nghiệp của chúng tôi tại phần của chúng tôi tại RIT++ 2017. Tại CodeFest 2017 (xem. ), Sergey Orlov và Mikhail Prokopchuk đã giải thích chi tiết lý do tại sao chúng tôi cần chuyển đổi sang microservice và Kubernetes đóng vai trò gì ở đây. Chà, hiện tại chúng tôi đang làm mọi thứ để giảm thiểu chi phí mở rộng quy mô vốn có trong một kiến trúc như vậy.
Ban đầu, chúng tôi không tạo ra một hệ sinh thái có thể giúp chúng tôi phát triển và triển khai các dịch vụ vi mô một cách toàn diện. Họ chỉ đơn giản là thu thập các giải pháp nguồn mở hợp lý, tung ra chúng tại nhà và mời nhà phát triển giải quyết chúng. Kết quả là anh đã đi đến hàng chục nơi (bảng điều khiển, dịch vụ nội bộ), sau đó anh càng trở nên mạnh mẽ hơn với mong muốn cắt mã theo cách cũ, nguyên khối. Màu xanh lục trong sơ đồ bên dưới biểu thị những gì nhà phát triển thực hiện theo cách này hay cách khác bằng chính đôi tay của mình và màu vàng biểu thị quá trình tự động hóa.
Giờ đây, trong tiện ích PaaS CLI, một dịch vụ mới được tạo bằng một lệnh và cơ sở dữ liệu mới được thêm hai lệnh nữa và được triển khai vào Giai đoạn.
Làm thế nào để vượt qua kỷ nguyên “phân mảnh microservice”
Với kiến trúc nguyên khối, vì mục đích nhất quán trong các thay đổi của sản phẩm, các nhà phát triển buộc phải tìm hiểu xem điều gì đang xảy ra với những người hàng xóm của họ. Khi làm việc trên kiến trúc mới, các bối cảnh dịch vụ không còn phụ thuộc vào nhau nữa.
Ngoài ra, để kiến trúc microservice phát huy hiệu quả cần phải thiết lập nhiều quy trình, cụ thể:
• khai thác gỗ;
• truy tìm yêu cầu (Jaeger);
• tổng hợp lỗi (Sentry);
• trạng thái, tin nhắn, sự kiện từ Kubernetes (Xử lý luồng sự kiện);
• giới hạn cuộc đua/ngắt mạch (bạn có thể sử dụng Hystrix);
• kiểm soát kết nối dịch vụ (chúng tôi sử dụng Netramesh);
• giám sát (Grafana);
• lắp ráp (TeamCity);
• liên lạc và thông báo (Slack, email);
• theo dõi nhiệm vụ; (Jira)
• chuẩn bị tài liệu.
Để đảm bảo hệ thống không bị mất tính toàn vẹn và vẫn hoạt động hiệu quả khi mở rộng quy mô, chúng tôi đã suy nghĩ lại về cách tổ chức các vi dịch vụ trong Avito.
Cách chúng tôi quản lý microservice
Trợ giúp sau đây để triển khai “chính sách đảng phái” thống nhất giữa nhiều dịch vụ vi mô Avito:
- chia cơ sở hạ tầng thành các lớp;
- Khái niệm Nền tảng là Dịch vụ (PaaS);
- giám sát mọi thứ xảy ra với microservice.
Các lớp trừu tượng hóa cơ sở hạ tầng bao gồm ba lớp. Hãy đi từ trên xuống dưới.
A. Lưới dịch vụ hàng đầu. Lúc đầu, chúng tôi đã thử Istio, nhưng hóa ra nó sử dụng quá nhiều tài nguyên, quá đắt so với khối lượng của chúng tôi. Do đó, kỹ sư cao cấp trong nhóm kiến trúc Alexander Lukyanchenko đã phát triển giải pháp của riêng mình - (có sẵn trong Nguồn mở), mà chúng tôi hiện đang sử dụng trong sản xuất và tiêu thụ tài nguyên ít hơn nhiều lần so với Istio (nhưng không làm được mọi thứ mà Istio có thể tự hào).
B. Trung bình - Kubernetes. Chúng tôi triển khai và vận hành microservice trên đó.
C. Đáy - kim loại trần. Chúng tôi không sử dụng đám mây hoặc những thứ như OpenStack mà hoàn toàn dựa vào kim loại trần.
Tất cả các lớp được kết hợp bởi PaaS. Và nền tảng này lần lượt bao gồm ba phần.
I. Máy phát điện, được điều khiển thông qua tiện ích CLI. Chính cô ấy là người giúp nhà phát triển tạo ra một microservice theo cách phù hợp và tốn ít công sức nhất.
II. Bộ sưu tập hợp nhất với quyền kiểm soát tất cả các công cụ thông qua một bảng điều khiển chung.
III. Kho. Kết nối với bộ lập lịch tự động đặt trình kích hoạt cho các hành động quan trọng. Nhờ hệ thống như vậy, không một nhiệm vụ nào bị bỏ sót chỉ vì ai đó quên thiết lập nhiệm vụ trong Jira. Chúng tôi sử dụng một công cụ nội bộ có tên Atlas cho việc này.
Việc triển khai các dịch vụ vi mô trong Avito cũng được thực hiện theo một sơ đồ duy nhất, giúp đơn giản hóa việc kiểm soát chúng ở từng giai đoạn phát triển và phát hành.
Quy trình phát triển microservice tiêu chuẩn hoạt động như thế nào?
Nói chung, chuỗi tạo microservice trông như thế này:
CLI-push → Tích hợp liên tục → Nướng → Triển khai → Thử nghiệm nhân tạo → Thử nghiệm Canary → Thử nghiệm ép → Sản xuất → Bảo trì.
Chúng ta hãy đi qua nó chính xác theo thứ tự này.
CLI-đẩy
• Tạo một vi dịch vụ.
Chúng tôi đã nỗ lực trong một thời gian dài để dạy mọi nhà phát triển cách thực hiện các dịch vụ vi mô. Điều này bao gồm việc viết hướng dẫn chi tiết trong Confluence. Nhưng các kế hoạch đã thay đổi và được bổ sung. Kết quả là một nút thắt đã xuất hiện ngay từ đầu hành trình: mất nhiều thời gian hơn để khởi chạy các dịch vụ vi mô và vẫn còn các vấn đề thường nảy sinh trong quá trình tạo ra chúng.
Cuối cùng, chúng tôi đã xây dựng một tiện ích CLI đơn giản giúp tự động hóa các bước cơ bản khi tạo một vi dịch vụ. Trong thực tế, nó thay thế git push đầu tiên. Đây chính xác là những gì cô ấy làm.
— Tạo một dịch vụ theo mẫu - từng bước, ở chế độ “thuật sĩ”. Chúng tôi có các mẫu cho các ngôn ngữ lập trình chính trong phần phụ trợ Avito: PHP, Golang và Python.
- Mỗi lần một lệnh triển khai môi trường phát triển cục bộ trên một máy cụ thể - Minikube được khởi chạy, biểu đồ Helm được tạo và khởi chạy tự động trong kubernetes cục bộ.
- Kết nối cơ sở dữ liệu cần thiết. Nhà phát triển không cần biết IP, thông tin đăng nhập và mật khẩu để có quyền truy cập vào cơ sở dữ liệu mà anh ta cần - có thể là cục bộ, tại Giai đoạn hoặc trong sản xuất. Hơn nữa, cơ sở dữ liệu được triển khai ngay lập tức với cấu hình có khả năng chịu lỗi và cân bằng.
- Nó tự thực hiện việc lắp ráp trực tiếp. Giả sử một nhà phát triển đã sửa lỗi nào đó trong một vi dịch vụ thông qua IDE của mình. Tiện ích này nhìn thấy những thay đổi trong hệ thống tệp và dựa trên chúng, xây dựng lại ứng dụng (cho Golang) và khởi động lại. Đối với PHP, chúng tôi chỉ cần chuyển tiếp thư mục bên trong khối và ở đó tải lại trực tiếp sẽ được lấy “tự động”.
- Tạo các bài kiểm tra tự động. Ở dạng trống, nhưng khá phù hợp để sử dụng.
• Triển khai microservice.
Việc triển khai một microservice từng là một công việc khó khăn đối với chúng tôi. Những điều sau đây được yêu cầu:
I. Dockerfile.
II. Cấu hình.
III. Biểu đồ Helm, bản thân nó rất cồng kềnh và bao gồm:
- bản thân các biểu đồ;
- mẫu;
- các giá trị cụ thể có tính đến các môi trường khác nhau.
Chúng tôi đã loại bỏ sự khó khăn khi làm lại các bảng kê khai Kubernetes để giờ đây chúng được tạo tự động. Nhưng quan trọng nhất, họ đã đơn giản hóa việc triển khai đến mức giới hạn. Từ bây giờ chúng ta có Dockerfile và nhà phát triển ghi toàn bộ cấu hình vào một tệp app.toml ngắn duy nhất.
Có, và trong app.toml không có gì để làm trong một phút. Chúng tôi chỉ định vị trí và số lượng bản sao của dịch vụ sẽ được tạo ra (trên máy chủ nhà phát triển, trên dàn dựng, trong sản xuất) và cho biết các phụ thuộc của dịch vụ đó. Lưu ý dòng size="small" trong khối [engine]. Đây là giới hạn sẽ được phân bổ cho dịch vụ thông qua Kubernetes.
Sau đó, dựa trên cấu hình, tất cả các biểu đồ Helm cần thiết sẽ được tạo tự động và các kết nối tới cơ sở dữ liệu sẽ được tạo.
• Xác nhận cơ bản. Việc kiểm tra như vậy cũng được tự động hóa.
Cần theo dõi:
- có Dockerfile không;
— có app.toml không;
- có tài liệu sẵn có không?
- sự phụ thuộc có theo thứ tự không?
— liệu các quy tắc cảnh báo đã được đặt chưa.
Đến điểm cuối cùng: chủ sở hữu dịch vụ tự xác định số liệu sản phẩm nào cần theo dõi.
• Chuẩn bị tài liệu.
Vẫn là một khu vực có vấn đề. Tưởng chừng như đó là điều hiển nhiên nhất nhưng đồng thời nó cũng là kỷ lục “thường bị lãng quên”, và do đó là mắt xích dễ bị tổn thương trong chuỗi.
Điều cần thiết là phải có tài liệu cho từng microservice. Nó bao gồm các khối sau.
I. Mô tả ngắn gọn về dịch vụ. Nghĩa đen là một vài câu về những gì nó làm và tại sao nó lại cần thiết.
II. Liên kết sơ đồ kiến trúc. Điều quan trọng là chỉ cần nhìn lướt qua, bạn có thể dễ dàng hiểu được, chẳng hạn như bạn đang sử dụng Redis để lưu vào bộ đệm hay làm kho lưu trữ dữ liệu chính ở chế độ liên tục. Hiện tại, trong Avito đây là một liên kết đến Confluence.
III. sổ tay. Hướng dẫn ngắn gọn về cách bắt đầu dịch vụ và những điều phức tạp khi xử lý nó.
IV. Câu hỏi thường gặp, sẽ rất tốt nếu bạn lường trước những vấn đề mà đồng nghiệp của bạn có thể gặp phải khi làm việc với dịch vụ.
V. Mô tả điểm cuối của API. Nếu đột nhiên bạn không chỉ định đích đến, những đồng nghiệp có microservice liên quan đến dịch vụ của bạn gần như chắc chắn sẽ trả tiền cho việc đó. Bây giờ chúng tôi sử dụng Swagger và giải pháp của chúng tôi được gọi là tóm tắt cho việc này.
VI. Nhãn. Hoặc các điểm đánh dấu cho biết dịch vụ thuộc về sản phẩm, chức năng hoặc bộ phận cấu trúc nào của công ty. Chúng giúp bạn nhanh chóng hiểu được, chẳng hạn như liệu bạn có đang cắt giảm chức năng mà đồng nghiệp của bạn đã triển khai cho cùng một đơn vị kinh doanh một tuần trước hay không.
VII. Chủ sở hữu hoặc chủ sở hữu dịch vụ. Trong hầu hết các trường hợp, nó — hoặc chúng — có thể được xác định tự động bằng PaaS, nhưng để đảm bảo an toàn, chúng tôi yêu cầu nhà phát triển chỉ định chúng theo cách thủ công.
Cuối cùng, cách tốt nhất là xem lại tài liệu, tương tự như xem lại mã.
Hội nhập liên tục
- Đang chuẩn bị kho lưu trữ.
- Tạo một đường dẫn trong TeamCity.
- Đặt quyền.
- Tìm kiếm chủ sở hữu dịch vụ. Ở đây có một sơ đồ kết hợp - đánh dấu thủ công và tự động hóa tối thiểu từ PaaS. Sơ đồ hoàn toàn tự động không thành công khi các dịch vụ được chuyển giao để hỗ trợ cho nhóm phát triển khác hoặc, chẳng hạn như nếu nhà phát triển dịch vụ bỏ cuộc.
- Đăng ký dịch vụ trên Atlas (xem ở trên). Với tất cả chủ sở hữu và phụ thuộc của nó.
- Kiểm tra di chuyển. Chúng tôi kiểm tra xem có bất kỳ điều nào trong số chúng có khả năng gây nguy hiểm hay không. Ví dụ: ở một trong số chúng, bảng thay đổi hoặc thứ gì đó khác bật lên có thể phá vỡ tính tương thích của lược đồ dữ liệu giữa các phiên bản khác nhau của dịch vụ. Sau đó, quá trình di chuyển không được thực hiện mà được đặt trong một đăng ký - PaaS phải báo hiệu cho chủ sở hữu dịch vụ khi thấy an toàn để sử dụng nó.
Nướng
Giai đoạn tiếp theo là đóng gói dịch vụ trước khi triển khai.
- Xây dựng ứng dụng. Theo kinh điển - trong hình ảnh Docker.
- Tạo biểu đồ Helm cho chính dịch vụ và các tài nguyên liên quan. Bao gồm cả cơ sở dữ liệu và bộ đệm. Chúng được tạo tự động theo cấu hình app.toml được tạo ở giai đoạn đẩy CLI.
- Tạo ticket cho admin mở port (khi cần thiết).
- Chạy thử nghiệm đơn vị và tính toán phạm vi mã. Nếu phạm vi phủ sóng của mã dưới ngưỡng được chỉ định thì rất có thể dịch vụ sẽ không tiến xa hơn - để triển khai. Nếu nó ở mức có thể chấp nhận được thì dịch vụ sẽ được gán hệ số “bi quan”: sau đó, nếu không có sự cải thiện về chỉ số theo thời gian, nhà phát triển sẽ nhận được thông báo rằng không có tiến bộ nào về mặt thử nghiệm ( và cần phải làm gì đó về nó).
- Tính toán các giới hạn về bộ nhớ và CPU. Chúng tôi chủ yếu viết các microservices bằng Golang và chạy chúng trong Kubernetes. Do đó, có một sự tinh tế gắn liền với đặc thù của ngôn ngữ Golang: theo mặc định, khi khởi động, tất cả các lõi trên máy sẽ được sử dụng, nếu bạn không đặt rõ ràng biến GOMAXPROCS và khi một số dịch vụ như vậy được khởi chạy trên cùng một máy, chúng sẽ bắt đầu tranh giành tài nguyên, gây trở ngại cho nhau. Các biểu đồ bên dưới cho thấy thời gian thực thi thay đổi như thế nào nếu bạn chạy ứng dụng mà không bị tranh chấp và trong chế độ chạy đua giành tài nguyên. (Nguồn của đồ thị là ).
Thời gian thực hiện càng ít càng tốt. Tối đa: 643ms, tối thiểu: 42ms. Bức ảnh có thể nhấp vào được.
Thời gian phẫu thuật càng ít càng tốt. Tối đa: 14091 ns, tối thiểu: 151 ns. Bức ảnh có thể nhấp vào được.
Ở giai đoạn chuẩn bị lắp ráp, bạn có thể đặt biến này một cách rõ ràng hoặc bạn có thể sử dụng thư viện từ những người đến từ Uber.
Triển khai
• Kiểm tra các quy ước. Trước khi bắt đầu phân phối các cụm dịch vụ đến môi trường dự định của mình, bạn cần kiểm tra những điều sau:
- Điểm cuối API.
— Tuân thủ các phản hồi của điểm cuối API với lược đồ.
- Định dạng nhật ký.
— Đặt tiêu đề cho các yêu cầu đối với dịch vụ (hiện tại việc này được thực hiện bởi netramesh)
— Đặt mã thông báo chủ sở hữu khi gửi tin nhắn đến bus sự kiện. Điều này là cần thiết để theo dõi kết nối của các dịch vụ trên xe buýt. Bạn có thể gửi cả dữ liệu bình thường đến xe buýt, điều này không làm tăng khả năng kết nối của dịch vụ (điều này tốt) và dữ liệu kinh doanh giúp tăng cường khả năng kết nối của dịch vụ (điều này rất tệ!). Và tại thời điểm kết nối này trở thành vấn đề, việc hiểu ai ghi và đọc bus sẽ giúp phân tách các dịch vụ một cách hợp lý.
Chưa có nhiều hội nghị ở Avito, nhưng nhóm của họ đang mở rộng. Càng có nhiều thỏa thuận như vậy ở dạng mà nhóm có thể hiểu và hiểu được thì việc duy trì tính nhất quán giữa các dịch vụ vi mô càng dễ dàng hơn.
Xét nghiệm tổng hợp
• Kiểm tra vòng kín. Đối với điều này, chúng tôi hiện đang sử dụng nguồn mở . Đầu tiên, nó ghi lại tải thực sự trên dịch vụ, sau đó - chỉ trong một vòng khép kín - nó mô phỏng tải đó.
• Bài kiểm tra về áp lực. Chúng tôi cố gắng mang mọi dịch vụ đến hiệu suất tối ưu. Và tất cả các phiên bản của mỗi dịch vụ đều phải trải qua quá trình kiểm tra tải - bằng cách này chúng ta có thể hiểu được hiệu suất hiện tại của dịch vụ và sự khác biệt so với các phiên bản trước của cùng một dịch vụ. Nếu sau khi cập nhật dịch vụ, hiệu suất của nó giảm đi một lần rưỡi thì đây là một tín hiệu rõ ràng cho chủ sở hữu của nó: bạn cần phải đào sâu vào mã và khắc phục tình trạng này.
Ví dụ: chúng tôi sử dụng dữ liệu đã thu thập để triển khai tự động mở rộng quy mô một cách chính xác và cuối cùng, nói chung là hiểu được khả năng mở rộng của dịch vụ.
Trong quá trình kiểm tra tải, chúng tôi kiểm tra xem mức tiêu thụ tài nguyên có đáp ứng giới hạn đã đặt hay không. Và chúng tôi tập trung chủ yếu vào các thái cực.
a) Chúng tôi xem xét tổng tải.
- Quá nhỏ - rất có thể có thứ gì đó không hoạt động nếu tải đột ngột giảm xuống nhiều lần.
- Quá lớn - cần tối ưu hóa.
b) Chúng tôi xem xét điểm cắt theo RPS.
Ở đây chúng ta xem xét sự khác biệt giữa phiên bản hiện tại và phiên bản trước đó cũng như tổng số lượng. Ví dụ: nếu một dịch vụ tạo ra 100 rps, thì dịch vụ đó được viết kém hoặc đây là tính đặc thù của nó, nhưng trong mọi trường hợp, đây là lý do để xem xét dịch vụ đó thật chặt chẽ.
Ngược lại, nếu có quá nhiều RPS thì có lẽ đã xảy ra một loại lỗi nào đó và một số điểm cuối đã ngừng thực thi tải trọng và một số lỗi khác chỉ đơn giản được kích hoạt return true;
bài kiểm tra Canary
Sau khi vượt qua các bài kiểm tra tổng hợp, chúng tôi kiểm tra vi dịch vụ trên một số ít người dùng. Chúng tôi bắt đầu một cách cẩn thận, với một tỷ lệ rất nhỏ đối tượng mục tiêu của dịch vụ - dưới 0,1%. Ở giai đoạn này, điều rất quan trọng là phải đưa các số liệu kỹ thuật và sản phẩm chính xác vào quá trình giám sát để chúng hiển thị vấn đề trong dịch vụ nhanh nhất có thể. Thời gian tối thiểu cho bài kiểm tra canary là 5 phút, bài kiểm tra chính là 2 giờ. Đối với các dịch vụ phức tạp, chúng tôi đặt thời gian theo cách thủ công.
Chúng tôi phân tích:
- các số liệu dành riêng cho ngôn ngữ, đặc biệt là các nhân viên php-fpm;
— lỗi trong Sentry;
- trạng thái phản hồi;
- thời gian đáp ứng, chính xác và trung bình;
- độ trễ;
- các ngoại lệ, đã được xử lý và chưa được xử lý;
- số liệu sản phẩm.
Kiểm tra sức ép
Kiểm tra sức ép còn được gọi là thử nghiệm "ép". Tên của kỹ thuật này đã được đưa vào Netflix. Bản chất của nó là trước tiên chúng ta lấp đầy một phiên bản bằng lưu lượng truy cập thực đến mức không thành công và do đó đặt ra giới hạn của nó. Sau đó, chúng tôi thêm một phiên bản khác và tải cặp này - lại ở mức tối đa; chúng ta nhìn thấy trần nhà và vùng đồng bằng của chúng bằng cú “ép” đầu tiên. Vì vậy, chúng tôi kết nối từng phiên bản một và tính toán mô hình thay đổi.
Dữ liệu thử nghiệm thông qua việc "ép" cũng chảy vào cơ sở dữ liệu số liệu chung, nơi chúng tôi làm phong phú thêm các kết quả tải giả tạo bằng chúng hoặc thậm chí thay thế "tổng hợp" bằng chúng.
Sản xuất
• Chia tỷ lệ. Khi triển khai một dịch vụ vào sản xuất, chúng tôi sẽ theo dõi quy mô của dịch vụ đó. Theo kinh nghiệm của chúng tôi, việc chỉ theo dõi các chỉ số CPU là không hiệu quả. Tự động mở rộng quy mô với điểm chuẩn RPS ở dạng thuần túy hoạt động nhưng chỉ đối với một số dịch vụ nhất định, chẳng hạn như phát trực tuyến. Vì vậy, trước tiên chúng tôi xem xét các số liệu sản phẩm dành riêng cho ứng dụng.
Kết quả là, khi mở rộng quy mô, chúng tôi phân tích:
- Chỉ báo CPU và RAM,
- số lượng yêu cầu trong hàng đợi,
- thời gian đáp ứng,
- dự báo dựa trên dữ liệu lịch sử được tích lũy.
Khi mở rộng quy mô một dịch vụ, điều quan trọng là phải giám sát các phần phụ thuộc của dịch vụ đó để chúng tôi không mở rộng quy mô dịch vụ đầu tiên trong chuỗi và những dịch vụ mà dịch vụ đó truy cập không thành công khi tải. Để thiết lập mức tải có thể chấp nhận được cho toàn bộ nhóm dịch vụ, chúng tôi xem xét dữ liệu lịch sử của dịch vụ phụ thuộc “gần nhất” (dựa trên sự kết hợp giữa các chỉ báo CPU và RAM, cùng với các chỉ số dành riêng cho ứng dụng) và so sánh chúng với dữ liệu lịch sử của dịch vụ khởi tạo, v.v. trong suốt “chuỗi phụ thuộc” ", từ trên xuống dưới.
Dịch vụ
Sau khi microservice được đưa vào hoạt động, chúng ta có thể gắn trigger vào nó.
Dưới đây là những tình huống điển hình trong đó các yếu tố kích hoạt xảy ra.
- Đã phát hiện các cuộc di cư nguy hiểm tiềm ẩn.
- Cập nhật bảo mật đã được phát hành.
— Bản thân dịch vụ này đã không được cập nhật trong một thời gian dài.
— Tải dịch vụ đã giảm đáng kể hoặc một số chỉ số sản phẩm của nó nằm ngoài phạm vi bình thường.
— Dịch vụ không còn đáp ứng được yêu cầu của nền tảng mới.
Một số trình kích hoạt chịu trách nhiệm đảm bảo sự ổn định của hoạt động, một số - như một chức năng bảo trì hệ thống - ví dụ: một số dịch vụ đã không được triển khai trong một thời gian dài và hình ảnh cơ sở của nó đã không vượt qua được kiểm tra bảo mật.
bảng điều khiển
Tóm lại, bảng điều khiển là bảng điều khiển của toàn bộ PaaS của chúng tôi.
- Một điểm thông tin duy nhất về dịch vụ, với dữ liệu về phạm vi thử nghiệm, số lượng hình ảnh, số lượng bản sao sản xuất, phiên bản, v.v.
- Một công cụ lọc dữ liệu theo dịch vụ và nhãn (điểm đánh dấu thuộc về đơn vị kinh doanh, chức năng sản phẩm, v.v.)
- Một công cụ tích hợp với các công cụ cơ sở hạ tầng để theo dõi, ghi nhật ký và giám sát.
- Một điểm duy nhất của tài liệu dịch vụ.
- Một quan điểm duy nhất về tất cả các sự kiện trên các dịch vụ.
trong tổng số
Trước khi giới thiệu PaaS, nhà phát triển mới có thể dành vài tuần để tìm hiểu tất cả các công cụ cần thiết để triển khai một vi dịch vụ trong quá trình sản xuất: Kubernetes, Helm, các tính năng TeamCity nội bộ của chúng tôi, thiết lập kết nối tới cơ sở dữ liệu và bộ nhớ đệm theo cách có khả năng chịu lỗi, v.v. mất vài giờ để đọc phần khởi động nhanh và tự tạo dịch vụ.
Tôi đã báo cáo về chủ đề này cho HighLoad++ 2018, bạn có thể xem nó и .
Bonus track cho ai đọc đến cuối
Tại Avito, chúng tôi đang tổ chức khóa đào tạo nội bộ kéo dài ba ngày cho các nhà phát triển từ , một chuyên gia về kiến trúc microservice. Chúng tôi muốn trao cơ hội tham gia vào nó cho một trong những độc giả của bài đăng này. Chương trình đào tạo đã được đăng tải.
Khóa đào tạo sẽ diễn ra từ ngày 5 đến ngày 7 tháng XNUMX tại Moscow. Đây là những ngày làm việc sẽ được lấp đầy hoàn toàn. Bữa trưa và buổi đào tạo sẽ diễn ra tại văn phòng của chúng tôi và người tham gia được chọn sẽ tự chi trả chi phí đi lại và ăn ở.
Bạn có thể đăng ký tham gia . Từ bạn - câu trả lời cho câu hỏi tại sao bạn cần tham gia khóa đào tạo và thông tin về cách liên hệ với bạn. Trả lời bằng tiếng Anh, vì Chris sẽ tự mình chọn người tham gia khóa đào tạo.
Chúng tôi sẽ công bố tên của người tham gia đào tạo trong bản cập nhật cho bài đăng này và trên mạng xã hội Avito dành cho nhà phát triển (AvitoTech in , , ) chậm nhất là ngày 19 tháng XNUMX.
Nguồn: www.habr.com