Style Characteristics (คุณลักษณะของ Style)

คะแนน 1 ดาว ในตาราง characteristics ratings ใน Figure 14-8 หมายความว่า architecture characteristic นั้นไม่ได้รับการรองรับที่ดีนักใน architecture ในขณะที่คะแนน 5 ดาวหมายความว่า architecture characteristic นั้นเป็นจุดแข็งที่สุดอย่างหนึ่งของ architectural style นี้ นิยามของแต่ละ characteristic ที่ระบุใน scorecard สามารถดูได้ใน Chapter 4 .

Figure 14-8. คะแนน characteristics ของ service-based architecture

service-based architecture เป็น architecture แบบ domain-partitioned หมายความว่าโครงสร้างของมันขับเคลื่อนโดย domain มากกว่าข้อพิจารณาเชิงเทคนิค (เช่น presentation logic หรือ persistence logic)

ลองพิจารณาตัวอย่างแอปพลิเคชัน recycling อุปกรณ์อิเล็กทรอนิกส์ Going Green ซึ่งเราแนะนำไว้ใน Chapter 7 และกลับมาพูดถึงอีกครั้งใน Chapter 13 สำหรับจุดประสงค์ของบทนี้ ลองสมมติว่า Going Green ใช้ service-based architecture style แต่ละ service ซึ่งเป็น unit ของซอฟต์แวร์ที่ deploy แยกกัน จะถูกกำหนดขอบเขตไว้ที่ domain เฉพาะ (เช่น item assessment) การเปลี่ยนแปลงภายใน domain นี้จะกระทบเฉพาะ service นั้นและ UI กับฐานข้อมูลที่เกี่ยวข้องเท่านั้น ไม่มีอะไรอื่นต้องแก้ไขเพื่อรองรับการเปลี่ยนแปลงด้าน assessment เฉพาะนั้น

ใน distributed architecture จำนวน quanta สามารถมากกว่าหรือเท่ากับหนึ่งได้ ตัวอย่างเช่น ถ้า service ทั้งหมดของ Going Green แชร์ฐานข้อมูลหรือ UI เดียวกัน ระบบทั้งหมดก็จะมี quantum เดียว อย่างไรก็ตาม ดังที่กล่าวถึงใน “Style Specifics” ทั้ง UI และฐานข้อมูลสามารถถูกแยกออกจากกันได้ (federated) ส่งผลให้เกิดหลาย quanta ภายในระบบโดยรวม ใน Figure 14-9 ระบบของ Going Green มีสอง quanta หนึ่งคือส่วนที่ลูกค้าเห็น ซึ่งมี UI, ฐานข้อมูล และชุด service สำหรับลูกค้าแยกต่างหาก ( Quoting และ Item Status ) อีกส่วนหนึ่งเกี่ยวข้องกับการดำเนินงานภายในของการรับ ประเมิน และ recycle อุปกรณ์อิเล็กทรอนิกส์ แม้ quantum ของการดำเนินงานภายในจะมี service ที่ deploy แยกกันและ UI สองตัวแยกกัน แต่ทั้งหมดก็แชร์ฐานข้อมูลเดียวกัน ทำให้ส่วนการดำเนินงานภายในของแอปพลิเคชันเป็น quantum เดียว

Figure 14-9. Quanta แยกกันใน service-based architecture

แม้เราจะไม่ได้ให้คะแนน 5 ดาวแก่ service-based architecture เลยสักด้าน แต่มันก็ยังได้คะแนนสูง (4 ดาว) ในหลายด้านที่สำคัญ การแยกแอปพลิเคชันออกเป็น domain service ที่ deploy แยกกันด้วย architectural style นี้ ช่วยให้เปลี่ยนแปลงได้เร็วขึ้น (agility), test coverage ดีขึ้นเนื่องจาก modularity ที่อิงตามขอบเขต domain (testability) และความสามารถในการ deploy บ่อยขึ้นโดยมีความเสี่ยงน้อยกว่า monolithic architecture (deployability) characteristic ทั้งสามนี้นำไปสู่ time to market ที่ดีขึ้น ทำให้องค์กรสามารถส่งมอบฟีเจอร์ใหม่และแก้บั๊กได้ค่อนข้างเร็ว

Fault tolerance และ availability โดยรวมของแอปพลิเคชันก็ได้คะแนนสูงสำหรับ service-based architecture เช่นกัน แม้ domain service มักมี granularity หยาบ แต่คะแนน 4 ดาวมาจากข้อเท็จจริงที่ว่า service ใน architectural style นี้มักเป็น self-contained และด้วยการแชร์โค้ดและฐานข้อมูล จึงมักไม่ใช้ interservice communication ผลก็คือ ถ้า domain service ตัวหนึ่งล่ม (เช่น service Receiving ของ Going Green) มันจะไม่กระทบ service อื่นอีกหกตัวเลย

Scalability ได้แค่ 3 ดาวเนื่องจากธรรมชาติแบบ coarse-grained ของ service ในทางกลับกัน elasticity ได้แค่ 2 ดาว แม้ scalability และ elasticity เชิงโปรแกรมจะเป็นไปได้แน่นอนกับ architectural style นี้ แต่มันก็ทำซ้ำฟังก์ชันการทำงานมากกว่า architecture style ที่มี service แบบ fine-grained กว่า (เช่น microservices) ทำให้คุ้มค่าน้อยกว่าและใช้ทรัพยากรเครื่องได้อย่างมีประสิทธิภาพน้อยกว่า โดยทั่วไป service-based architecture มักใช้ service แต่ละตัวเพียง instance เดียว เว้นแต่ต้องการ throughput หรือ failover ที่ดีกว่า ตัวอย่างที่ดีของสิ่งนี้ ดังแสดงใน Figure 14-9 คือ Going Green—มีเพียง service Quoting และ Item Status เท่านั้นที่ต้อง scale เพื่อรองรับปริมาณลูกค้าสูง service ด้านปฏิบัติการอื่น ๆ ต้องการแค่ instance เดียว ทำให้รองรับสิ่งต่าง ๆ เช่น in-memory caching ตัวเดียวและ database-connection pooling ได้ง่ายขึ้น

ความเรียบง่ายและต้นทุนโดยรวมเป็นปัจจัยสำคัญอีกสองอย่างที่ทำให้ architectural style นี้แตกต่างจาก distributed architecture อื่นที่แพงและซับซ้อนกว่า เช่น microservices, event-driven architecture หรือแม้แต่ space-based architecture นี่ทำให้ service-based เป็นหนึ่งใน distributed architecture ที่ implement ได้ง่ายและคุ้มค่าที่สุด แม้ว่านี่จะเป็นข้อเสนอที่น่าสนใจ แต่ก็มี trade-off เช่นเคย ยิ่งต้นทุนและความซับซ้อนสูงขึ้นเท่าไร characteristic 4 ดาวเหล่านี้ (เช่น scalability, elasticity และ fault tolerance) ก็จะยิ่งดีขึ้นเท่านั้น

ความยืดหยุ่นของมัน รวมกับ architecture characteristic ระดับ 3 ดาวและ 4 ดาวมากมาย ทำให้ service-based architecture เป็นหนึ่งใน style ที่ pragmatic ที่สุดที่มีอยู่ แม้จะมี distributed architectural style ที่ทรงพลังกว่ามาก แต่หลายบริษัทก็พบว่าพลังขนาดนั้นมาพร้อมราคาที่สูงเกินไป บางบริษัทก็พบว่าพวกเขาแค่ไม่ จำเป็น ต้องใช้พลังขนาดนั้น มันเหมือนกับการซื้อ Ferrari มาแค่ขับไปทำงานในช่วงเวลาเร่งด่วน—มันดูเท่ก็จริง แต่ช่างเป็นการสูญเปล่าของพลัง ความเร็ว และความคล่องตัว!

service-based architecture ยังเหมาะกับ domain-driven design โดยธรรมชาติ เนื่องจาก service มี granularity หยาบและถูกกำหนดขอบเขตตาม domain แต่ละ domain จึงเข้ากันได้ดีกับ service ที่ deploy แยกกันซึ่งครอบคลุม domain นั้นโดยเฉพาะ การรวมฟังก์ชันการทำงานนั้นไว้ในหน่วยซอฟต์แวร์เดียวทำให้การเปลี่ยนแปลง domain นั้นทำได้ง่ายขึ้น

การดูแลรักษาและประสานงาน database transaction เป็นปัญหาที่พบเสมอใน distributed architecture ซึ่งมักพึ่งพา eventual consistency (หมายความว่าการอัปเดตฐานข้อมูลที่เป็นอิสระจากกันจะซิงก์กันในที่สุด) มากกว่า ACID transaction แบบดั้งเดิม (หมายความว่าการอัปเดตฐานข้อมูลถูกประสานและทำร่วมกันใน unit of work เดียว) service-based architecture ใช้ประโยชน์จาก ACID transaction ได้ดีกว่า distributed architecture style อื่นใด เพราะ domain service ของมันมี granularity หยาบ นั่นหมายความว่า transaction scope ถูกกำหนดไว้ที่ domain service เฉพาะตัวหนึ่ง ทำให้รองรับฟังก์ชัน commit-and-rollback transaction แบบดั้งเดิมที่พบในแอปพลิเคชัน monolithic ส่วนใหญ่ได้

สุดท้าย service-based architecture เป็นตัวเลือกที่ดีสำหรับสถาปนิกที่ต้องการบรรลุ modularity ในระดับที่ดีโดยไม่ต้องเข้าไปพัวพันกับความซับซ้อนของ granularity และการประสาน service (ดู “Choreography and Orchestration” ใน Chapter 18 )