BÁO cáo phát triển phần mềm hướng dịch vụ chapter 6phân tích và tạo mô hình với các dịch vụ web và microservices

Học viện Cơng nghệ Bưu Viễn Thơng *** BÁO CÁO Phát triển phần mềm hướng dịch vụ Chapter 6: Phân tích tạo mơ hình với dịch vụ web Microservices Giảng viên: Đặng Ngọc Hùng Nguyễn Đắc Long B18DCCN350 Lại Thái Việt B18DCCN688 Đỗ Minh Thành B18DCCN612 MỤC LỤC: 6.1 Quy trình mơ hình hóa dịch vụ web .2 6.1.1 Bước 1: Phân tách Quy trình kinh doanh 6.1.2 Bước 2: Lọc hành động không phù hợp 6.1.3 Bước 3: Xác định ứng cử viên entity service (Define Entity Service Candidates) 10 6.1.4 Bước 4: Xác định logic cụ thể quy trình(Identify Process-Specific Logic) 15 6.1.5 Bước 5: Áp dụng hướng dịch vụ 17 6.1.6 Bước 6: Xác định ứng cử viên thành phần dịch vụ .19 6.1.7 Bước 7: Phân tích yêu cầu xử lý 20 6.1.8 Bước 8: Xác định ứng viên dịch vụ tiện ích 22 6.1.9 Bước 9: Xác định ứng viên Microservice (Define Microservice Candidates) 23 6.1.10 Bước 10: Áp dụng Định hướng Dịch vụ (Apply Service-Orientation) 24 6.1.11 Bước 11: Điều chỉnh ứng cử viên thành phần dịch vụ 25 6.1.12 Bước 12: Sửa đổi nhóm ứng viên lực .26 Nội dung 6.1 Quy trình mơ hình hóa dịch vụ web Về bản, quy trình mơ hình hóa dịch vụ xem tập việc tổ chức thông tin thu thập Bước quy trình phân tích hướng dịch vụ gốc mơ tả Chương Hình 6.1 cung cấp quy trình mơ hình hóa dịch vụ chung phù hợp cho dịch vụ Web tùy chỉnh thêm Chương theo sau dịch vụ chung trình mơ hình hóa cách mơ tả bước cung cấp thêm ví dụ nghiên cứu điển hình Hình 6.1 Quy trình mơ hình hóa dịch vụ mẫu cho dịch vụ Web 6.1.1 Bước 1: Phân tách Quy trình kinh doanh Chúng tơi bắt đầu cách sử dụng quy trình kinh doanh lập thành văn chia nhỏ thành loạt bước quy trình chi tiết Logic quy trình cơng việc quy trình kinh doanh cần phân tách thành trình bày chi tiết bước xử lý, khác với mức mức độ chi tiết mà bước quy trình ban đầu lập thành văn Ví dụ nghiên cứu điển hình Dưới bảng phân tích bước quy trình kinh doanh tại: Nhận Bảng chấm cơng Xác minh Bảng chấm công Nếu Bảng chấm công xác minh, chấp nhận việc gửi lên kết thúc bảng chấm công Từ chối gửi bảng chấm cơng Mặc dù bao gồm bốn bước thời điểm này, doanh nghiệp nhiều quy trình Các chi tiết tiết lộ nhóm TLS phân tích logic quy trình Họ bắt đầu với bước Nhận Bảng chấm công, chia thành hai bước nhỏ hơn: 1a Nhận tài liệu bảng chấm công vật lý 1b Bắt đầu đệ trình Bảng chấm cơng Bước Xác minh Bảng chấm cơng thực quy trình theo nghĩa đó, chia nhỏ thành bước chi tiết sau: 2a So sánh số ghi Bảng chấm công với số lập hóa đơn cho khách hàng 2b Xác nhận cấp phép cho làm thêm ghi 2c Xác nhận số ghi lại cho dự án cụ thể không vượt Giới hạn xác định trước cho dự án 2d Xác nhận Tổng số ghi lại tuần không vượt mức tối đa xác định trước cho người lao động Khi phân tích tiếp theo, TLS phát thêm Bảng chấm công từ chối Bước quy trình đệ trình phân tích thành bước chi tiết sau: 4a Cập nhật Hồ sơ Người lao động để Theo dõi Bảng chấm công bị Từ chối 4b Phát hành Thông báo từ chối Bảng chấm công cho Nhân viên 4c Đưa Thông báo cho Người quản lý Người lao động Sau sâu vào bước quy trình ban đầu, TLS có lượng lớn bước quy trình Nó tổ chức bước thành quy trình kinh doanh mở rộng quy trình làm việc (Hình 6.3): • Nhận Bảng chấm cơng • So sánh số ghi Bảng chấm công với số lập hóa đơn cho khách hàng Hình 6.3 Quy trình nghiệp vụ Đệ trình Bảng chấm công TLS sửa đổi Nếu số không khớp, từ chối việc gửi bảng chấm cơng • Xác nhận cấp phép cho làm thêm ghi • Nếu xác nhận ủy quyền không thành công, từ chối gửi bảng chấm cơng • Xác nhận số ghi cho dự án cụ thể không vượt a Giới hạn xác định trước cho dự án • Xác nhận Tổng số ghi lại tuần không vượt mức tối đa xác định trước cho người lao động • Nếu xác nhận ghi không thành công, từ chối gửi bảng chấm cơng • Từ chối gửi Bảng chấm cơng • Tạo thơng báo giải thích lý từ chối • Phát hành Thơng báo từ chối Bảng chấm cơng cho Nhân viên • Đưa Thông báo cho Người quản lý Người lao động • Nếu Bảng chấm công xác minh, chấp nhận việc đệ trình kết thúc quy trình chấm cơng Cuối cùng, TLS đơn giản hóa logic quy trình nghiệp vụ thành tập hợp sau hành động chi tiết: • Nhận Bảng chấm cơng • Bắt đầu đệ trình Bảng chấm cơng • Nhận số ghi lại cho khách hàng phạm vi ngày • Nhận Giờ lập hóa đơn cho Khách hàng Phạm vi Ngày • So sánh số ghi với số lập hóa đơn • Nếu số không khớp, từ chối việc gửi bảng chấm cơng • Nhận làm thêm cho phạm vi ngày • Nhận ủy quyền • Xác nhận ủy quyền • Nếu xác nhận ủy quyền không thành công, từ chối gửi bảng chấm cơng • Nhận giới hạn số hàng tuần • So sánh giới hạn số hàng tuần với số ghi • Nếu xác nhận ghi không thành công, từ chối gửi bảng chấm cơng • Cập nhật lịch sử nhân viên • Gửi tin nhắn cho nhân viên • Gửi tin nhắn cho người quản lý • Nếu Bảng chấm công xác minh, chấp nhận việc đệ trình kết thúc quy trình chấm cơng 6.1.2 Bước 2: Lọc hành động không phù hợp Một số bước quy trình kinh doanh dễ dàng xác định không thuộc tiềm logic cần đóng gói ứng viên dịch vụ Chúng bao gồm quy trình thủ cơng bước không nên tự động hóa bước xử lý kế thừa có thực logic mà gói ứng viên dịch vụ tùy chọn Bằng cách lọc phần này, chúng tơi cịn lại với bước xử lý phù hợp với quy trình tạo mơ hình dịch vụ chúng tơi Ví dụ nghiên cứu điển hình Sau xem xét bước quy trình kinh doanh, bước khơng thể không làm không thuộc giải pháp hướng dịch vụ bị loại bỏ Danh sách sau truy cập lại hành động bị phân hủy Hành động bị gạch bỏ thực nhân viên kế tốn thực thủ cơng • Nhận Bảng chấm cơng • Bắt đầu đệ trình Bảng chấm cơng • Nhận số ghi lại cho khách hàng phạm vi ngày • Nhận Giờ lập hóa đơn cho Khách hàng Phạm vi Ngày • So sánh số ghi với số lập hóa đơn • Nếu số khơng khớp, từ chối việc gửi bảng chấm cơng • Nhận làm thêm cho phạm vi ngày • Nhận ủy quyền • Xác nhận ủy quyền • Nếu xác nhận ủy quyền không thành công, từ chối gửi bảng chấm công • Nhận giới hạn số hàng tuần • So sánh giới hạn số hàng tuần với số ghi • Nếu xác nhận ghi khơng thành cơng, từ chối gửi bảng chấm cơng • Cập nhật lịch sử nhân viên • Gửi tin nhắn cho nhân viên • Gửi tin nhắn cho người quản lý • Nếu Bảng chấm cơng xác minh, chấp nhận việc đệ trình kết thúc quy trình chấm cơng Mỗi hành động cịn lại coi ứng cử viên khả phục vụ 6.1.3 Bước 3: Xác định ứng cử viên entity service (Define Entity Service Candidates) Xem lại bước xử lý lại xác định nhiều ngữ cảnh hợp lý mà bước nhóm lại Mỗi ngữ cảnh đại diện cho ứng viên dịch vụ Các bối cảnh mà bạn kết thúc phụ thuộc vào loại hình dịch vụ kinh doanh mà bạn chọn để xây dựng Ví dụ, task service yêu cầu ngữ cảnh cụ thể cho quy trình, entity service đưa nhu cầu nhóm bước xử lý theo mối quan hệ chúng với thực thể xác định trước SOA bao gồm kết hợp loại dịch vụ kinh doanh Điều quan trọng bạn không nên quan tâm đến việc có bước thuộc nhóm Mục đích thiết lập tập hợp ngữ cảnh cần thiết Việc trang bị cho ứng viên dịch vụ thực thể với ứng viên lực bổ sung để tạo điều kiện sử dụng lại tương lai khuyến khích Do đó, phạm vi bước mở rộng để bao gồm phân tích ứng viên lực dịch vụ bổ sung khơng quy trình kinh doanh u cầu, thêm vào để hoàn thiện dịch vụ thực thể với tập hợp hoàn chỉnh hoạt động tái sử dụng Case Study Example Các nhà phân tích nghiệp vụ TLS hỗ trợ nỗ lực mơ hình hóa dịch vụ cách tạo mơ hình thực thể có liên quan đến logic quy trình nghiệp vụ Gửi bảng chấm cơng (Hình 4) 10 • Nếu số khơng khớp, từ chối việc gửi bảng chấm cơng • Nhận làm thêm cho phạm vi ngày • Nhận ủy quyền • Xác nhận ủy quyền • Nếu xác nhận ủy quyền khơng thành cơng, từ chối gửi bảng chấm cơng • Nhận giới hạn số hàng tuần • So sánh giới hạn số hàng tuần với số ghi • Nếu xác nhận ghi khơng thành cơng, từ chối gửi bảng chấm cơng • Cập nhật lịch sử nhân viên • Gửi tin nhắn cho nhân viên • Gửi tin nhắn cho người quản lý • Nếu bảng chấm công xác minh, chấp nhận việc đệ trình kết thúc quy trình chấm công Đầu tiên, thực thể Bảng chấm công xem xét Thực thể đảm bảo ứng cử viên entity service tương ứng gọi đơn giản “Timesheet” Sau phân tích thuộc tính nó, TLS xác định thêm ứng viên khả dịch vụ sau nên nhóm với ứng viên entity servce : • Nhận số ghi lại cho khách hàng phạm vi ngày • Nhận làm thêm cho phạm vi ngày • Nhận ủy quyền 12 Tuy nhiên, phân tích tiếp theo, người ta xác định hai ứng cử viên khả tái sử dụng nhiều cách loại bỏ yêu cầu phạm vi ngày tiêu chí truy vấn Mặc dù quy trình kinh doanh cụ thể cung cấp phạm vi ngày, nhà phân tích kinh doanh quy trình khác muốn yêu cầu ghi lại làm thêm làm thêm dựa thông số khác Kết tập hợp ứng cử viên lực sửa đổi, Hình Hình 5: Ứng cử viên dịch vụ Timesheet Sau đó, nhà phân tích xem xét thực thể Invoice Một lần nữa, họ đồng ý thực thể xứng đáng đại diện ứng cử viên entity service độc lập Họ đặt tên cho dịch vụ “Invoice” gán cho ứng cử viên lực sau: • Nhận Giờ lập hóa đơn cho khách hàng phạm vi ngày Khi nguyên tắc hướng dịch vụ khả tái sử dụng dịch vụ xem xét lại, nhà phân tích định mở rộng phạm vi ứng viên dịch vụ cách điều chỉnh chức ứng viên lực chọn sau thêm chức mới, thể Hình Giờ đây, người tiêu dùng dịch vụ truy xuất thơng tin khách hàng liên quan đến hóa đơn thơng tin lập hóa đơn cách riêng biệt 13 Hình 6: Ứng cử viên dịch vụ Invoice Các thực thể Employee Employee History xem xét Bởi họ có liên quan chặt chẽ với nhau, nên định họ đại diện chung ứng viên service gọi “Employee” Hai ứng viên khả phục vụ định, dẫn đến định nghĩa ứng viên service hiển thị Hình Hình 7: Ứng viên dịch vụ Employee Nhóm TLS xem xét việc thêm ứng viên khả dịch vụ Gửi thông báo vào ứng viên dịch vụ Nhân viên, sau xác định chức 14 tốt nên tách riêng thành ứng viên dịch vụ tiện ích Do đó, hai hành động cịn lại tạm dừng dịch vụ tiện ích xác định, phần sau q trình này: • Gửi tin nhắn cho nhân viên • Gửi tin nhắn cho người quản lý 6.1.4 Bước 4: Xác định logic cụ thể quy trình(Identify Process-Specific Logic) Bất kỳ phần logic quy trình kinh doanh cịn lại sau chúng tơi hồn thành Bước cần phân loại non-agnostic dành riêng cho quy trình kinh doanh Các loại hành động phổ biến thuộc danh mục bao gồm quy tắc nghiệp vụ, logic có điều kiện, logic ngoại lệ logic trình tự sử dụng để thực hành động quy trình nghiệp vụ riêng lẻ Lưu ý khơng phải tất hành động non-agnostic thiết phải trở thành ứng cử viên khả phục vụ Nhiều hành động dành riêng cho quy trình biểu thị logic định dạng xử lý khác thực thi logic dịch vụ Note Có thể có đủ thông tin non-agnostic logic xác định để xác định xem phần logic phù hợp để đóng gói nhiều dịch vụ vi mô hay không Trong trường hợp này, microservice xác định phần bước với ứng viên dịch vụ tác vụ Tuy nhiên, bạn nên đợi đến Bước để thức xác định microservice(s) cần thiết cho giải pháp bước mơ hình hóa dịch vụ tới xác định logic nonagnostic bổ sung hỗ trợ thêm cho việc xác định yêu cầu xử lý thực giải pháp Case Study Example Các hành động sau coi non-agnostic chúng dành riêng cho quy trình nghiệp vụ Timesheet Submission: • Bắt đầu đệ trình Bảng chấm cơng 15 • So sánh số ghi với số lập hóa đơn • Nếu số khơng khớp, từ chối việc gửi bảng chấm cơng • Xác nhận ủy quyền • Nếu xác nhận ủy quyền không thành công, từ chối gửi bảng chấm công • So sánh giới hạn số hàng tuần với số ghi • Nếu xác nhận ghi không thành công, từ chối gửi bảng chấm cơng • Nếu Bảng chấm cơng xác minh, chấp nhận việc đệ trình kết thúc quy trình chấm công Biểu mẫu hoạt động Timesheet Submission tạo sở cho ứng viên lực dịch vụ, giải thích phần mơ tả ứng viên dịch vụ nhiệm vụ Timesheet Submission tới Các hành động lại in đậm để chúng đại diện cho logic thực dịch vụ nhiệm vụ Đệ trình biểu thời gian, sau thực hành động Bắt đầu đệ trình biểu thời gian, hành động đổi tên thành ứng cử viên khả dịch vụ Bắt đầu (Hình 8) Hình 8: Ứng viên dịch vụ Đệ trình Bảng chấm cơng với dịch vụ khả khởi chạy tự động hóa nghiệp vụ Gửi Bảng chấm cơng tiến trình 16 6.1.5 Bước 5: Áp dụng hướng dịch vụ Bước giúp ta có hội điều chỉnh áp dụng nguyên tắc chủ chốt phần mềm hướng dịch vụ Tùy thuộc vào hiểu biết sâu sắc mà chúng tơi có chất logic cụ thể yêu cầu ứng viên dịch vụ định, chúng tơi có hội để phát triển phạm vi cấu trúc ứng viên dịch vụ Các nguyên tắc Service Loose Coupling, Service Abstraction Service Autonomy giúp đưa cân nhắc phù hợp giai đoạn Service Loose Coupling  Định nghĩa ngắn gọn: "Các dịch vụ kết hợp chặt chẽ với nhau."  Định nghĩa dài: "Các hợp đồng dịch vụ đặt yêu cầu kết hợp người tiêu dùng thấp thân chúng tách biệt khỏi môi trường xung quanh chúng."  Mục tiêu: Bằng cách liên tục thúc đẩy giảm bớt khớp nối bên dịch vụ, nỗ lực hướng tới trạng thái nơi hợp đồng dịch vụ tăng tính độc lập khỏi việc triển khai dịch vụ ngày độc lập với Điều thúc đẩy mơi trường dịch vụ người tiêu dùng họ phát triển cách thích ứng theo thời gian với tác động tối thiểu đến  Đặc điểm thiết kế: o Sự tồn hợp đồng dịch vụ tách biệt cách lý tưởng khỏi công nghệ chi tiết thực o Một bối cảnh dịch vụ chức không phụ thuộc vào logic bên o Yêu cầu tối thiểu khớp nối người tiêu dùng  Yêu cầu tích hợp: o Các dịch vụ kết hợp lỏng lẻo thường thực nhiều xử lý thời gian chạy chúng kết hợp chặt chẽ Do đó, việc trao đổi liệu nói chung tiêu tốn nhiều tài nguyên thời gian chạy hơn, đặc biệt trường hợp truy cập đồng thời sử dụng nhiều o Để đạt cân phù hợp khớp nối, đồng thời hỗ trợ nguyên tắc định hướng dịch vụ khác có ảnh hưởng đến thiết kế hợp đồng, địi hỏi phải nâng cao trình độ thiết kế hợp đồng dịch vụ 17 Service Abstraction  Định nghĩa ngắn gọn: "Thông tin dịch vụ không thiết yếu trừu tượng hóa."  Định nghĩa dài: "Hợp đồng dịch vụ chứa thông tin cần thiết thông tin dịch vụ giới hạn cơng bố hợp đồng dịch vụ."  Mục tiêu: Nhiều nguyên tắc khác nhấn mạnh cần thiết phải công bố thêm thông tin hợp đồng dịch vụ Vai trị ngun tắc giữ cho số lượng chi tiết nội dung hợp đồng ngắn gọn cân đối, đồng thời ngăn chặn việc truy cập không cần thiết vào chi tiết dịch vụ bổ sung  Đặc điểm thiết kế: o Dịch vụ quán thông tin trừu tượng công nghệ, logic chức cách xa giới bên (thế giới bên ranh giới dịch vụ) o Dịch vụ có hợp đồng xác định ngắn gọn yêu cầu ràng buộc tương tác chi tiết meta dịch vụ bắt buộc khác o Bên ngồi ghi hợp đồng dịch vụ, thơng tin dịch vụ kiểm sốt ẩn hồn tồn mơi trường cụ thể  Yêu cầu tích hợp: Điều kiện tiên để đạt mức độ trừu tượng thích hợp cho dịch vụ mức độ kỹ thiết kế hợp đồng dịch vụ áp dụng Service Autonomy  Định nghĩa ngắn gọn: "Các dịch vụ tự trị."  Định nghĩa dài: "Các dịch vụ thực mức độ kiểm sốt cao mơi trường thực thi thời gian chạy chúng."  Mục tiêu: o Để tăng độ tin cậy, hiệu suất khả dự đoán thời gian chạy dịch vụ, đặc biệt sử dụng lại soạn thảo o Để tăng mức độ kiểm soát dịch vụ môi trường thời gian chạy o Bằng cách theo đuổi thiết kế độc lập môi trường thời gian chạy, chúng tơi hướng tới việc tăng cường kiểm sốt sau triển khai dịch vụ kiểm soát dịch vụ môi trường thực thi  Đặc điểm thiết kế: 18 o Các dịch vụ có hợp đồng thể ranh giới chức xác định rõ ràng không trùng lặp với dịch vụ khác o Các dịch vụ triển khai môi trường mà chúng thực nhiều quyền kiểm soát (và tốt mức độc quyền) o Các phiên dịch vụ lưu trữ mơi trường có tính đồng thời cao cho mục đích khả mở rộng  Yêu cầu tích hợp: o Mức độ kiểm sốt cao cách thiết kế phát triển logic dịch vụ Tùy thuộc vào mức độ tự chủ tìm kiếm, điều liên quan đến việc kiểm sốt mơ hình liệu hỗ trợ o Mơi trường triển khai phân phối, phép dịch vụ di chuyển, cô lập cấu thành theo yêu cầu o Cơ sở hạ tầng có khả hỗ trợ cấp độ tự chủ Ghi Đặc biệt, việc áp dụng nguyên tắc Service Autonomy làm nảy sinh cân nhắc dẫn đến nhu cầu đóng gói số logic xác định microservices Trong trường hợp này, ứng viên microservice xác định phần bước xem xét thêm Bước 9, microservice xác định rõ ràng 6.1.6 Bước 6: Xác định ứng cử viên thành phần dịch vụ Xác định tập hợp tình phổ biến diễn ranh giới quy trình kinh doanh Đối với tình huống, làm theo bước xử lý bắt buộc chúng tồn Bài tập hồn thành điều sau: • Cung cấp thơng tin chi tiết mức độ phù hợp việc nhóm bước quy trình bạn • Thể mối quan hệ tiềm ẩn lớp dịch vụ nhiệm vụ thực thể • Xác định thành phần dịch vụ tiềm • Đánh dấu bước xử lý logic quy trình làm việc bị thiếu Đảm bảo rằng, phần tình bạn chọn, bạn bao gồm điều kiện lỗi liên quan đến logic xử lý ngoại lệ Cũng lưu ý lớp dịch vụ bạn thiết lập thời điểm sơ sửa đổi q trình thiết kế 19 Ví dụ nghiên cứu điển hình Hình 6.9 hiển thị ứng viên thành phần dịch vụ sơ bao gồm ứng viên dịch vụ nhiệm vụ thực thể Mơ hình tổng hợp kết tình tổng hợp khác nhóm TLS vạch để khám phá điều kiện thành công thất bại khác thực tự động hóa quy trình Gửi Bảng chấm cơng Hình 6.9: Xem xét hệ thống phân cấp ứng viên cấu thành dịch vụ hình thành kịch tương tác dịch vụ khác khám phá giai đoạn Do kết việc lập biểu đồ hoạt động dịch vụ khác ranh giới ứng cử viên cấu thành dịch vụ này, TLS cảm thấy tin tưởng không thiếu logic quy trình phi bất khả tri so với xác định 6.1.7 Bước 7: Phân tích yêu cầu xử lý Đến cuối Bước 6, bạn tạo chế độ xem tập trung vào doanh nghiệp cho lớp dịch vụ Quan điểm bao gồm ứng cử viên dịch vụ tiện ích dịch vụ kinh doanh, trọng tâm thể logic quy trình kinh doanh Điều bước tới yêu cầu xác định phân tích yêu cầu xử lý thực ứng viên dịch vụ Chúng tơi làm điều để trừu tượng hóa logic dịch vụ tập trung vào cơng nghệ 20 đảm bảo đời microservices thêm vào lớp dịch vụ tiện ích Để thực điều này, bước xử lý xác định phải trải qua phân tích nhỏ Cụ thể, điều cần xác định là: • Logic xử lý cần thực để xử lý hành động mô tả ứng cử viên khả dịch vụ định • Liệu logic xử lý yêu cầu tồn hay chưa hay cần phát triển • Những tài ngun bên ngồi ranh giới dịch vụ mà logic xử lý cần để truy cập — ví dụ: sở liệu dùng chung, kho lưu trữ, thư mục, hệ thống kế thừa, v.v • Bất kỳ logic xử lý xác định có yêu cầu hiệu suất / độ tin cậy chuyên biệt quan trọng hay khơng • Liệu logic xử lý xác định có yêu cầu thực / môi trường chuyên biệt quan trọng hay không Lưu ý thông tin thu thập Bước q trình phân tích hướng dịch vụ gốc đề cập Chương tham chiếu điểm Ví dụ nghiên cứu điển hình Sau đánh giá yêu cầu xử lý ứng viên dịch vụ xác định logic quy trình kinh doanh tổng thể, nhóm TLS xác nhận hành động Gửi tin nhắn cho nhân viên Gửi tin nhắn cho người quản lý cần đóng gói phần lớp dịch vụ tiện ích Dựa thơng tin có sẵn yêu cầu xử lý biết môi trường triển khai dịch vụ cuối cùng, chúng xác định logic khác tập trung vào tiện ích Trong q trình xem xét logic quy trình khơng bất khả tri nằm phạm vi dịch vụ nhiệm vụ Đệ trình bảng chấm công, kiến trúc sư nhận thấy tồn khác biệt yêu cầu xử lý Đặc biệt, hành động Xác nhận Ủy quyền bao gồm logic yêu cầu để truy cập kho lưu trữ thông quan độc quyền Tương tác có yêu cầu SLA lớn đáng kể so với phần lại logic quy trình khơng bất khả tri liên quan đến hiệu suất chuyển đổi dự phòng Việc giữ logic nhóm với logic khác phần dịch vụ nhiệm vụ Gửi bảng chấm cơng có nguy khiến logic khơng thực thi theo số yêu cầu Do đó, đề xuất nên tách thành nhiều ứng cử viên microservice mà cuối hưởng lợi từ kiểu triển 21 khai tự trị cao đảm bảo hiệu suất cần thiết nhu cầu chuyển đổi dự phòng 6.1.8 Bước 8: Xác định ứng viên dịch vụ tiện ích Trong bước này, chúng tơi chia nhỏ đơn vị logic xử lý bất khả tri thành loạt hành động chi tiết Chúng ta cần phải rõ ràng việc gắn nhãn cho hành động để chúng tham chiếu đến chức mà chúng thực Tốt nhất, khơng tham chiếu đến bước quy trình nghiệp vụ mà chức định xác định Nhóm bước xử lý theo ngữ cảnh xác định trước Với ứng viên dịch vụ tiện ích, bối cảnh mối quan hệ logic ứng viên lực Mối quan hệ dựa yếu tố nào, bao gồm: • Liên kết với hệ thống kế thừa cụ thể • Liên kết với nhiều thành phần giải pháp • Phân nhóm logic theo loại chức Nhiều vấn đề khác tính vào sau ứng viên dịch vụ phải tuân theo quy trình thiết kế theo định hướng dịch vụ Hiện tại, việc nhóm thiết lập lớp dịch vụ tiện ích sơ Ví dụ nghiên cứu điển hình Sau đánh giá yêu cầu xử lý logic đủ điều kiện cho mơ hình dịch vụ tiện ích, nhóm TLS xem lại hành động Gửi tin nhắn cho nhân viên Gửi tin nhắn cho người quản lý nhóm chúng thành dịch vụ tiện ích tái sử dụng mới, gọi đơn giản Thông báo Để làm cho ứng viên dịch vụ tái sử dụng nhiều hơn, hai ứng viên lực hợp thành thể Hình 6.10 22 Hình 6.10: Ứng viên dịch vụ Thơng báo Ghi Mơ hình hóa ứng viên dịch vụ tiện ích tiếng khó so với ứng viên dịch vụ thực thể Không giống dịch vụ thực thể, nơi đặt bối cảnh ranh giới chức dựa mơ hình đặc điểm kinh doanh doanh nghiệp lập thành văn (chẳng hạn phân loại, thể học, mối quan hệ thực thể, v.v.), thường khơng có mơ cho logic ứng dụng Do đó, phạm vi chức bối cảnh ứng viên dịch vụ tiện ích thường sửa đổi liên tục lần lặp lại chu trình phân tích hàng tồn kho dịch vụ 6.1.9 Bước 9: Xác định ứng viên Microservice (Define Microservice Candidates) Bây chuyển ý đến logic xử lý non-agnostic xác định trước để xác định xem liệu đơn vị logic đủ điều kiện để đóng gói microservice riêng biệt hay khơng Mơ hình microservice giới thiệu kiến trúc triển khai dịch vụ độc lập tự chủ cao phù hợp với đơn vị logic với nhu cầu xử lý cụ thể Những cân nhắc điển hình bao gồm: • Tăng u cầu quyền tự chủ • Yêu cầu hiệu suất thời gian chạy cụ thể 23 • Các yêu cầu độ tin cậy chuyển đổi dự phòng cụ thể thời gian chạy • Các yêu cầu triển khai lập phiên dịch vụ cụ thể Điều quan trọng cần lưu ý nhu cầu triển khai chuyên biệt họ, việc sử dụng dịch vụ Web dựa SOAP khơng phù hợp với microservice, chúng xác định phần quy trình mơ hình hóa dịch vụ tập trung vào dịch vụ Web Các kiến trúc sư SOA cung cấp tùy chọn để xây dựng dịch vụ vi mô cách sử dụng công nghệ triển khai thay thế, giới thiệu giao thức truyền thông riêng biệt độc quyền Case Study Example Hành động Confirm Autorization phần logic ứng viên dịch vụ nhiệm vụ Đệ trình Bảng chấm công tách để tạo sở cho ứng viên microservice Confirm Autorization, dịch vụ REST thực logic thơng qua ứng viên Confirm Hình 11: Ứng viên dịch vụ Confirm Autorization 6.1.10 Step 10: Áp dụng Định hướng Dịch vụ (Apply ServiceOrientation) Bước bước lặp lại Bước 7, cung cấp đặc biệt cho ứng viên dịch vụ tiện ích xuất sau hoàn thành Bước 24 6.1.11 Bước 11: Điều chỉnh ứng cử viên thành phần dịch vụ Xem lại tình ban đầu mà bạn xác định Bước chạy lại chúng, lần kết hợp dịch vụ tiện ích ứng cử viên lực Điều dẫn đến lập đồ hoạt động phức tạp nhằm đưa sáng tác dịch vụ mở rộng vào sống Chắc chắn theo dõi cách ứng viên dịch vụ kinh doanh liên kết với ứng viên dịch vụ tiện ích tập Ví dụ nghiên cứu điển hình Với đời dịch vụ tiện ích Thơng báo Bảng chấm công xác minh microservice, nước da thành phần Đệ trình Bảng chấm cơng Hệ thống phân cấp thay đổi đáng kể, minh họa Hình 6.12 Hình 6.12 Ứng cử viên thành phần dịch vụ sửa đổi kết hợp với tiện ích dịch vụ dịch vụ vi mô 25 6.1.12 Bước 12: Sửa đổi nhóm ứng viên lực Thực ánh xạ kịch hoạt động từ Bước 11 thường dẫn đến thay đổi để phân nhóm định nghĩa ứng viên lực dịch vụ Nó làm bật thiếu sót bước xử lý bắt buộc khác, dẫn đến việc bổ sung dịch vụ ứng viên lực chí ứng viên dịch vụ 26 ... dịch vụ Web dựa SOAP khơng phù hợp với microservice, chúng xác định phần quy trình mơ hình hóa dịch vụ tập trung vào dịch vụ Web Các kiến trúc sư SOA cung cấp tùy chọn để xây dựng dịch vụ vi mô cách... triển khai dịch vụ kiểm soát dịch vụ mơi trường thực thi  Đặc điểm thiết kế: 18 o Các dịch vụ có hợp đồng thể ranh giới chức xác định rõ ràng không trùng lặp với dịch vụ khác o Các dịch vụ triển. .. cầu, thêm vào để hoàn thiện dịch vụ thực thể với tập hợp hoàn chỉnh hoạt động tái sử dụng Case Study Example Các nhà phân tích nghiệp vụ TLS hỗ trợ nỗ lực mơ hình hóa dịch vụ cách tạo mơ hình thực