Examples and Use Cases (ตัวอย่างและกรณีการใช้งาน)

เพื่อแสดงความยืดหยุ่นและพลังของ service-based architectural style เราจะกลับมาดูตัวอย่าง Going Green ระบบที่ใช้ recycle อุปกรณ์อิเล็กทรอนิกส์เก่า (เช่น iPhone หรือมือถือ Galaxy) อีกครั้ง

processing flow ของ Going Green ทำงานดังนี้:

  1. ลูกค้าถาม Going Green (ผ่านเว็บไซต์หรือ kiosk) ว่าจะจ่ายเงินเท่าไรสำหรับอุปกรณ์อิเล็กทรอนิกส์เก่า ( quoting )

  2. ถ้าพอใจกับราคาที่เสนอ ลูกค้าจะส่งอุปกรณ์ไปยังบริษัท recycling ( receiving )

  3. Going Green ประเมินสภาพของอุปกรณ์ ( assessment )

  4. ถ้าอุปกรณ์อยู่ในสภาพใช้งานได้ดี Going Green จะจ่ายเงินให้ลูกค้าสำหรับอุปกรณ์นั้น ( accounting ) ในระหว่างกระบวนการนี้ ลูกค้าสามารถเข้าเว็บไซต์เมื่อไรก็ได้เพื่อตรวจสอบสถานะของสินค้า ( item status )

  5. ตามผลการประเมิน Going Green จะทำลายอุปกรณ์อย่างปลอดภัยและนำชิ้นส่วนไป recycle หรือขายต่อบนแพลตฟอร์มขายของ third party เช่น Facebook Marketplace หรือ eBay ( recycling )

  6. Going Green รันรายงานทางการเงินและปฏิบัติการเกี่ยวกับกิจกรรม recycling เป็นระยะ ( reporting )

Figure 14-10 แสดงระบบนี้ที่ implement ด้วย service-based architecture แต่ละ domain area ที่เราเพิ่งระบุไปถูก implement เป็น domain service ที่ deploy แยกกันและเป็นอิสระ service ที่ต้อง scale (และดังนั้นจึงต้องมี service instance หลายตัว) คือ service ที่ต้องการ throughput สูงกว่า (ในกรณีนี้คือ service Quoting และ ItemStatus ที่ลูกค้าเห็น) เนื่องจาก service อื่นไม่จำเป็นต้อง scale จึงต้องการแค่ service instance เดียว

Electronics recycling example

Figure 14-10. แอปพลิเคชัน recycling อุปกรณ์อิเล็กทรอนิกส์ของ Going Green ที่ใช้ service-based architecture

ในตัวอย่างนี้ แอปพลิเคชัน UI ถูกแยกออกเป็น domain ได้แก่: Customer Facing , Receiving และ Recycling and Accounting การแยกนี้ให้ fault tolerance ที่ดีในระดับ UI, scalability ที่ดี และความปลอดภัยที่เหมาะสม (เนื่องจากลูกค้าภายนอกไม่มีเส้นทาง network ในการเข้าถึงฟังก์ชันภายใน) สังเกตด้วยว่ามีฐานข้อมูลจริงสองตัวแยกกัน: หนึ่งสำหรับการดำเนินงานที่ลูกค้าเห็น และอีกหนึ่งสำหรับการดำเนินงานภายใน การจัดวางแบบนี้ช่วยให้ข้อมูลและการดำเนินงานภายในอยู่ใน network zone แยกจากการดำเนินงานภายนอก (แสดงด้วยเส้นแนวนอน) มันยังให้ข้อจำกัดด้านความปลอดภัยและการป้องกันข้อมูลที่ดีกว่ามาก—และถือเป็น architectural quantum แยกต่างหาก การเข้าถึงผ่าน firewall แบบทางเดียวเท่านั้นที่อนุญาตให้ service ภายในเข้าถึงและอัปเดตข้อมูลที่ลูกค้าเห็นได้ แต่ไม่ใช่ในทางกลับกัน อีกทางเลือกหนึ่ง ขึ้นอยู่กับฐานข้อมูล ทีมยังสามารถใช้การทำ mirroring ตารางภายในและการซิงก์ตารางภายนอกเพื่อซิงก์ข้อมูลระหว่างสองฐานข้อมูลได้

นอกจากนี้ service Assessment ยังเปลี่ยนแปลงตลอดเวลา เนื่องจากมีผลิตภัณฑ์ใหม่เข้ามาหรือออกสู่ตลาดอยู่เรื่อย ๆ ด้วย service-based architecture การเปลี่ยนแปลงบ่อยครั้งเหล่านี้จะถูกแยกไว้ใน domain service เดียว ทำให้ได้ agility, testability และ deployability

service-based architecture เป็น architectural style ที่ยืดหยุ่นมาก ให้ทั้ง domain partitioning และระดับที่ดีของ scalability, agility, fault tolerance, availability และ responsiveness ในราคาที่ค่อนข้างถูก เมื่อเทียบกับ distributed architecture อื่น ปัจจัยเหล่านี้ทำให้มันเป็นตัวเลือกยอดนิยม

service-based architecture ยังเป็นเป้าหมายการย้ายระบบแบบ “stepping stone” ที่ดีสำหรับ distributed architecture อื่น ๆ ไม่ว่าองค์กรจะกำลังย้ายไปยัง distributed architecture style อื่น หรือกำลังสร้างระบบ distributed ใหม่ตั้งแต่ต้น สิ่งนี้นำเราไปสู่ประเด็นหลักของเรา:

ไม่ใช่ทุกส่วนของแอปพลิเคชันที่จำเป็นต้องเป็น microservices

Mark Richards

การย้ายไปยังหรือสร้าง service-based architecture เป็น “stepping stone” ก่อน จะย้ายไปยัง architectural style เป้าหมายในตอนแรก ช่วยให้ทีมวิเคราะห์ domain และตัดสินใจได้ว่าส่วนใดของ architecture ควร เป็น microservices ตัวอย่างเช่น ในตัวอย่าง Going Green service Recycling และ Accounting ไม่จำเป็นต้องแตกย่อยไปมากกว่านี้และควรคงเป็น domain service ต่อไป แต่ service Assessment เปลี่ยนแปลงบ่อยและต้องการ agility ระดับสูง ดังนั้น service นั้น จึงควรถูกแตกย่อยเป็น service แยกกัน หนึ่งตัวต่ออุปกรณ์อิเล็กทรอนิกส์แต่ละประเภท ถ้าทีม Going Green ข้ามขั้นตอนนี้ไปแล้วย้าย ตรง ไปสู่ microservices architecture เลย ฟังก์ชันการทำงาน ทุกส่วน ก็มีแนวโน้มจะกลายเป็น microservice แม้ว่าจะไม่จำเป็นต้องเป็นก็ตาม

นี่คือเหตุผลบางส่วนในหลาย ๆ เหตุผลที่ service-based architecture เป็นที่ชื่นชอบในหมู่สถาปนิก อย่างไรก็ตาม มันเป็นเพียงหนึ่งใน distributed architectural style ที่มีอยู่มากมาย และการเข้าใจทั้งหมดจะช่วยให้ตัดสินใจได้ว่าอะไรเหมาะสมที่สุดสำหรับปัญหาทางธุรกิจแต่ละอย่าง เพื่อให้เข้าใจมากขึ้น มาดู distributed architecture อื่น ๆ กันต่อ .