คาบนี้จะพาไปไหน

สามคาบแรกสอนเครื่องมือ: container คืออะไร สร้าง image ยังไง สั่งหลาย container พร้อมกันยังไง

คาบนี้ถอยออกมาหนึ่งก้าวแล้วถามว่า แล้วควรแบ่งซอฟต์แวร์ออกเป็นกี่ชิ้น และแบ่งตรงไหน

ส่วนที่ 1 — จาก monolith ไป microservices

เริ่มจากแอปตัวหนึ่งชื่อ SlowQueue

สไลด์ใช้แอปสมมติชื่อ SlowQueue เป็นตัวเดินเรื่องทั้งส่วนนี้ มันคือระบบจองคิวร้านอาหาร ประกอบด้วย

• Browser ที่รันหน้าเว็บแบบ SPA (Single Page Application) (เว็บหน้าเดียวที่โหลดครั้งเดียวแล้ววาดหน้าใหม่ด้วย JavaScript) คุยกลับมาด้วย HTML และ REST
• Tomcat AppServer หนึ่งตัว ที่ข้างในบรรจุสี่โมดูล — Web Frontend, Membership Management, Queue Management, Restaurant Management
• MySQL หนึ่งตัว เป็นฐานข้อมูลของทั้งระบบ

จุดสำคัญอยู่ที่คำว่า WAR/EAR ในรูป มันคือไฟล์แพ็กเกจของโลก Java — สี่โมดูลนั้นไม่ได้เป็นสี่โปรแกรม แต่ถูกคอมไพล์รวมเป็น ไฟล์เดียว แล้วรันอยู่ใน โปรเซสเดียว กัน

แบบนี้เรียกว่า Monolithic Architecture (สถาปัตยกรรมแบบก้อนเดียว) — สร้างครั้งเดียว ปล่อยครั้งเดียว ทั้งแอปขึ้นลงพร้อมกัน

monolith ไม่ใช่ของแย่

monolith เป็นจุดเริ่มต้นที่ถูกต้องในกรณีส่วนใหญ่ เพราะ

• รันได้บนเครื่องเดียวหรือไม่กี่เครื่อง ประหยัด latency (เวลาหน่วงต่อหนึ่งคำขอ) ต่ำ throughput (ปริมาณงานที่รองรับได้ต่อวินาที) สูง — เพราะการเรียกข้ามโมดูลคือการเรียกฟังก์ชันธรรมดา ไม่ใช่การส่งข้อมูลผ่านเครือข่าย
• build, test, deploy เป็นก้อนเดียว จบเร็ว
• เหมาะมากกับแอปเล็กที่มีทีมพัฒนาเล็ก

แล้วอะไรพัง

ปัญหาไม่ได้เริ่มจากโค้ด แต่เริ่มจาก จำนวนคน

สไลด์หน้า 7 วาดไว้ชัด: วันแรก SlowQueue 1.0 มีทีมพัฒนาทีมเดียว พอมาถึง SlowQueue 4.0 มันกลายเป็นห้าทีม — Web UI, Mobile UI, Queue Management, Backend และ Ads

ห้าทีม แต่ยังปล่อยของจากไฟล์เดียวกัน

สไลด์หน้า 8 สรุปข้อจำกัดไว้ห้าข้อ

ข้อสุดท้ายคือใจความ ไม่ใช่ว่า monolith ช้า แต่ว่า ทุกส่วนถูกบังคับให้เดินด้วยความเร็วเดียวกัน

เทคโนโลยีก็ค้างอยู่ตรงนั้นด้วย

สไลด์หน้า 9 เติมปัญหาอีกชั้น: ทีม Queue อยากใช้ Node.js เพราะขยายง่ายกว่า ทีม Backend อยากใช้ Python เพราะจะทำ ML pipeline

แต่ทั้งระบบเป็น J2EE ก้อนเดียว จะเปลี่ยนภาษาต้องเขียนใหม่หมด — too big to rewrite

เมื่อรวมกับหน้า 10 ที่บอกว่าธุรกิจเปลี่ยนเร็วมาก และสิ่งที่ต้องการคือขยับจาก stability (ความนิ่ง ไม่ค่อยเปลี่ยน) ไปหา agility (ความคล่องตัว เปลี่ยนได้ไว) คือส่งซอฟต์แวร์ได้ เร็ว บ่อย และเชื่อถือได้ ก็จะเห็นว่า monolith ไปต่อไม่ไหวแล้ว

Microservice Architecture คืออะไร

Microservice Architecture (สถาปัตยกรรมแบบบริการย่อย) เป็นรูปแบบหนึ่งของ SOA (Service-Oriented Architecture) (สถาปัตยกรรมที่จัดระบบเป็นชุดของบริการ) โดยมีลักษณะสี่ข้อ

1. จัดแอปเป็นชุดของบริการที่ไม่ผูกกันแน่น (loosely coupled (เกี่ยวข้องกันแบบหลวม ๆ))
2. บริการมีขนาดย่อย และโปรโตคอลที่ใช้คุยกันเบา — ปกติคือ REST
3. ไม่ผูกกับแพลตฟอร์ม ไม่ยึดระบบปฏิบัติการหรือภาษาใดภาษาหนึ่ง
4. แต่ละบริการโฟกัสความสามารถทางธุรกิจอย่างเดียว (single business capability)

ข้อ 4 คือเกณฑ์การแบ่ง ไม่ใช่แบ่งตามชั้นเทคนิค (controller / service / repository) แต่แบ่งตาม เรื่องทางธุรกิจ — คิว ร้านอาหาร โฆษณา สมาชิก

รูปที่ 3 มีของใหม่สี่อย่างที่ monolith ไม่มี

• Content Router ตัดสินใจว่าเบราว์เซอร์ควรได้หน้าเว็บของแอปไหน
• API Gateway ประตูเดียวสำหรับ client ที่เรียก API (จะพูดยาว ๆ ในส่วนที่ 3)
• Notification Gateway ทางออกสำหรับข้อความที่ระบบส่งหา client
• ฐานข้อมูลแยกต่อบริการ — ไม่ใช่ MySQL ก้อนเดียวอีกแล้ว

Data-Per-Service คือกฎที่ผิดกันบ่อยที่สุด

Data-Per-Service Pattern (แต่ละบริการถือฐานข้อมูลของตัวเอง) แปลว่าบริการ A ห้ามยิง SQL เข้าตารางของบริการ B ถึงจะรู้รหัสผ่านก็ห้าม

แนวคิดหลักสี่ข้อ

สไลด์หน้า 15 ย่อทั้งหมดเหลือสี่ข้อ ที่เหลือของคาบนี้คือการขยายสี่ข้อนี้

ไม่ผูกกับแพลตฟอร์มแปลว่าอะไร

เมื่อบริการคุยกันด้วย REST หรือ gRPC สิ่งที่ข้ามเส้นระหว่างบริการมีแค่ข้อความ ไม่ใช่ object ในหน่วยความจำ

ผลคือแต่ละบริการเลือกภาษาของตัวเองได้ — สไลด์หน้า 16 วาดไว้ว่าบริการหนึ่งลอง Python อีกตัวย้ายไป JavaScript อีกตัวเขียน Go

ทีมกับบริการเป็นเรื่องเดียวกัน

นี่คือหัวใจของทั้งเรื่อง แต่ละทีมมี repository ของตัวเอง มี Automated Deployment Pipeline (สายพานปล่อยของอัตโนมัติ ตั้งแต่ build ถึงขึ้นระบบ) ของตัวเอง และปล่อยบริการของตัวเอง

ประโยคที่สไลด์เขียนกำกับไว้คือ working independently most of the time — สังเกตคำว่า most ไม่ใช่ all ยังมีเวลาที่ต้องคุยกัน เช่นตอนจะเปลี่ยนสัญญาของ API

สิ่งที่ microservices ทำให้เกิดได้ (สไลด์หน้า 18)

• ซอฟต์แวร์ที่ไม่ผูกกันแน่น
• ทีมเล็กและคล่อง
• เปลี่ยนไปใช้เทคโนโลยีใหม่ได้ทีละส่วน
• ทำ DevOps ง่ายขึ้น — automated testing และ continuous delivery/deployment ทำได้จริง เพราะขอบเขตที่ต้องเทสต์ต่อรอบเล็กลงมาก

แล้วเสียอะไรไป

เกณฑ์ตัดสินจากสไลด์: เลือก microservices เมื่อสิ่งที่องค์กรได้กลับมา มีค่ามากกว่าราคาของการเป็นระบบกระจาย

สไลด์หน้า 19 ขยายฝั่งราคาอีกสี่ข้อ

• ออกแบบยาก — จะแบ่งตรงไหน แต่ละบริการควรใหญ่แค่ไหน
• สถาปัตยกรรมซับซ้อนขึ้น
• ระบบกระจายมาก ทำให้หา cascading failure (ความล้มเหลวลูกโซ่ ตัวหนึ่งล้มแล้วลามไปตัวอื่น) ได้ยาก
• ขั้นตอน test และ deploy ยุ่งกว่าเดิม

และตอนจบสไลด์เขียนว่า along comes Software-Defined Systems — สามข้อหลังคือปัญหาที่วิชานี้ทั้งวิชาเกิดมาแก้

ส่วนที่ 2 — microservices กับ container

container กับ microservice ไม่ใช่เรื่องเดียวกัน

สองอย่างนี้แก้คนละปัญหา

จากนั้นสไลด์ก็ระบุตรง ๆ ว่า container ไม่ได้ทำให้เกิด microservices

• monolith รันใน container ได้สบาย และก็ยังเป็น monolith อยู่ดี
• microservice หนึ่งตัวอาจใช้หลาย container หรือหลายโปรเซสก็ได้
• ขอบเขตของบริการมาจาก ความเป็นเจ้าของ ข้อมูล และการเปลี่ยนแปลงที่เป็นอิสระต่อกัน
• container แค่ทำให้ขอบเขตที่ขีดไว้แล้ว แพ็กและ deploy ได้ง่าย

ทำไมต้อง container ไม่ใช่ VM

คาบที่ 2 เทียบ VM กับ container ในเชิงโครงสร้างไปแล้ว คาบนี้เทียบในเชิง ตัวเลข สไลด์หน้า 23 ให้เหตุผลห้าข้อ

• แยกกันได้แน่นหนา (strong isolation)
• เบา overhead ต่ำกว่ามาก
• ขยายจำนวนง่าย
• บูตเร็วกว่ามาก
• สั่งงานแบบ declarative ได้ ซึ่งคือหัวใจของคำว่า software-defined

ข้อ "บูตเร็วกว่ามาก" มีข้อมูลจริงรองรับ

อ่านกราฟนี้ให้ถูกต้องอ่านแบบนี้

• ที่จำนวนน้อย (2–8 ตัว) แทบไม่ต่างกัน ประมาณ 3–13 วินาทีทั้งคู่ ถ้าคุณรัน 4 อย่างบนเครื่องพัฒนา VM ก็ไม่ได้ช้ากว่าจนรู้สึก
• ช่องว่างเปิดกว้างตามจำนวน ที่ 64 ตัว container ใช้ประมาณ 110 วินาที ส่วน VM ใช้ประมาณ 830 วินาที
• ที่ 256 ตัว ต่างกันเกินห้าสิบเท่า — ประมาณ 440 วินาที เทียบกับประมาณ 25,000 วินาที (เกือบเจ็ดชั่วโมง)
• ที่ 512 ตัว VM รันไม่ได้เลย เครื่องหมายกากบาทในกราฟคือจุดที่ VM ทำไม่สำเร็จ ส่วน container ยังขึ้นได้ในราวสิบห้านาที

เมื่อรันหลายบริการพร้อมกัน สิ่งที่จัดการทั้งหมดให้คือ container orchestration ซึ่งเป็นเรื่องของคาบหน้า

Compose แถม service discovery มาให้ฟรี

คาบที่ 3 สอนเขียน compose file ไปแล้ว คาบนี้เพิ่มมุมที่สำคัญสำหรับ microservices โดยเฉพาะ (สไลด์หน้า 27)

• ทุก service ใน project เดียวกันถูกต่อเข้า network ปริยายของ project อัตโนมัติ
• เรียกกันด้วยชื่อ service เช่น todo และ redis ไม่ใช่ IP ของ container
• การคุยกันระหว่างบริการใช้พอร์ตของ container ไม่ใช่พอร์ตที่ map ออกมาที่ host
• ports: มีไว้สำหรับทราฟฟิกที่เข้ามาจากข้างนอกเท่านั้น

ข้อสุดท้ายคือจุดที่คนพลาดบ่อยที่สุด และเราจะเห็นตัวอย่างจริงของมันในอีกไม่กี่หัวข้อ

ตัวอย่างที่จะเดินไปด้วยกันตลอดคาบ: Todo Service

สไลด์ใช้ repository จริงสี่ตัวบน GitHub ของอาจารย์ผู้สอน (ทั้งหมดเป็น GPL v3)

ตัว Todo Service เองทำแค่สามอย่าง — อ่าน เพิ่ม และแก้รายการสิ่งที่ต้องทำ โดยหนึ่งรายการมีห้าฟิลด์

{
  "title": "todo-1",
  "detail": "the first todo",
  "tags": [],
  "duedate": "2021-10-20 00:00:00",
  "completed": false
}

ขั้นที่ 1 — บริการเดียว

git clone https://github.com/natawutn/todo.git
cd todo
git tag
git checkout release-1.3
git describe

(base) natawut@mini ~/sds/git % git clone https://github.com/natawutn/todo.git
Cloning into 'todo'...
remote: Enumerating objects: 129, done.
remote: Counting objects: 100% (129/129), done.
remote: Compressing objects: 100% (93/93), done.
remote: Total 129 (delta 50), reused 103 (delta 24), pack-reused 0
Receiving objects: 100% (129/129), 29.31 KiB | 370.00 KiB/s, done.
Resolving deltas: 100% (50/50), done.
(base) natawut@mini ~/sds/git % cd todo
(base) natawut@mini ~/sds/git/todo % git tag
release-1
release-1.1
release-1.2
release-1.3
release-2
release-2.1
release-3
(base) natawut@mini ~/sds/git/todo % git describe
release-3
(base) natawut@mini ~/sds/git/todo % git checkout release-1.3
HEAD is now at 1cfe3cf Version 1.2.3 - Revise readme file to contain docker information
(base) natawut@mini ~/sds/git/todo % git describe
release-1.3

ขั้นที่ 2 — เพิ่มหน้าเว็บ

หน้าเว็บอยู่ที่ natawutn/todo-webapp เป็น JavaScript รันบน Node.js ขณะที่บริการหลังบ้านเป็น Python + FastAPI — นี่คือข้อ "ไม่ผูกกับแพลตฟอร์ม" ที่พูดไว้ในส่วนที่ 1 ปรากฏเป็นของจริง

FROM node:16-alpine
RUN apk update
RUN apk add git
COPY . /root/todo-webapp
WORKDIR /root/todo-webapp
RUN yarn install
EXPOSE 3000
ENV TODO_ENDPOINT http://todo:8000/
CMD yarn start

บรรทัดที่สำคัญที่สุดคือ

ENV TODO_ENDPOINT http://todo:8000/

คำว่า todo ตรงนี้ ไม่ใช่ชื่อโฮสต์บนอินเทอร์เน็ต แต่เป็นชื่อ container ซึ่งจะแปลเป็น IP ได้ก็ต่อเมื่อ container ทั้งสองอยู่บนเครือข่ายเดียวกัน — ถ้าไม่อยู่ จะได้ error ว่าหาโฮสต์ไม่เจอ

และสังเกตว่าเลข 8000 ตรงนี้คือ พอร์ตของ container ไม่ใช่พอร์ตที่ map ออก host ตรงตามกฎในสไลด์หน้า 27

git checkout release-1.2
docker build -t todo-webapp:release-1 .
docker run -i --rm --name webapp -p 3000:3000 todo-webapp:release-1

natawut@ares:~/todo/todo-webapp$ docker run -i --rm --name webapp -p 3000:3000 todo-webapp:release-1
yarn run v1.22.5
$ react-scripts start
i ｢wds｣: Project is running at http://172.17.0.3/
i ｢wds｣: webpack output is served from
i ｢wds｣: Content not from webpack is served from /root/todo-webapp/public
i ｢wds｣: 404s will fallback to /
Starting the development server...

Browserslist: caniuse-lite is outdated. Please run the following command: `npx browserslist --update-db`
Compiled successfully!

You can now view todo-webapp in the browser.

  Local:            http://localhost:3000
  On Your Network:  http://172.17.0.3:3000

Note that the development build is not optimized.
To create a production build, use yarn build.

ขั้นที่ 3 — ยกขึ้น Compose

ตอนนี้ต้องพิมพ์ docker run สองครั้งทุกรอบ และต้องจำลำดับด้วย สไลด์จึงย้ายไป natawutn/todo-compose

git checkout release-1
docker-compose up
docker-compose down

ไฟล์ compose ของ release-1 หน้าตาแบบนี้

services:
  todo:
    image: "todo:release-1.3"
    container_name: todo
    ports:
      - 8000:8000
  webapp:
    image: "todo-webapp:release-1"
    container_name: webapp
    stdin_open: true
    ports:
      - 3000:3000

stdin_open: true คือ -i ของ docker run — หน้าเว็บที่รันด้วย react-scripts start ต้องการ stdin เปิดไว้ ไม่งั้นมันจะปิดตัวเอง

ขั้นที่ 4 — เพิ่ม Redis แล้วเจอปัญหาจริง

Todo Service รุ่นใหม่ (src=release-2.1, img=release-2) เก็บข้อมูลลง Redis (ฐานข้อมูลแบบเก็บในหน่วยความจำ อ่านเขียนเร็วมาก) แทนที่จะเก็บในหน่วยความจำของตัวเอง

สิ่งที่น่าสนใจคือ หน้าเว็บยังเป็น release-1.2 เหมือนเดิม ไม่ต้องแก้อะไรเลย เพราะสัญญาของ REST API ไม่เปลี่ยน ที่เปลี่ยนคือของภายในบริการ นี่คือ Encapsulation (การห่อรายละเอียดภายในไว้ไม่ให้คนนอกเห็น) ทำงานจริง

ลองสั่งแบบเดิม

docker run -i --rm --name todo -p 8000:8000 todo:release-2
docker run -i --rm --name redis -p 6379:6379 redis

แล้ว todo จะเรียก redis ที่พอร์ต 6379 ได้ยังไง?

ทางแก้คือสร้างเครือข่ายของตัวเองแล้วเอาทั้งคู่ไปอยู่ด้วยกัน

docker network create todo-net
docker network connect todo-net todo
docker network connect todo-net redis

ผลที่ได้สองอย่าง

1. todo เรียก redis:6379 ได้ตรง ๆ เพราะ Docker แปลชื่อ container เป็น IP ให้บนเครือข่ายที่ผู้ใช้สร้างเอง
2. redis ไม่ต้อง map พอร์ตออก host เลย — ซึ่งดีต่อความปลอดภัยด้วย เพราะไม่มีใครจากข้างนอกยิงเข้าฐานข้อมูลได้

คำสั่งเต็มชุดที่สไลด์ให้ไว้ สั่งเครือข่ายพร้อมกับตอนสร้าง container ได้เลย ไม่ต้อง connect ทีหลัง

docker network create todo-net

docker run -d --rm --name redis --network todo-net redis

docker run -d --rm --name todo --network todo-net \
  --env REDIS_HOST=redis -p 8000:8000 todo:release-2

docker run -d -t --rm --name webapp --network todo-net \
  -p 3000:3000 todo-webapp:release-1

--env REDIS_HOST=redis คือวิธีบอกบริการว่าฐานข้อมูลอยู่ที่ไหน โดยไม่ต้องแก้โค้ดและไม่ต้อง build image ใหม่ — ที่อยู่ของของอื่นเป็น การตั้งค่า ไม่ใช่ส่วนหนึ่งของโปรแกรม

ขั้นที่ 4 เขียนเป็น compose file

services:
  todo:
    image: "todo:release-2"
    container_name: todo
    ports:
      - 8000:8000
    environment:
      REDIS_HOST: redis
    networks:
      - todo-net

  webapp:
    image: "todo-webapp:release-1"
    container_name: webapp
    stdin_open: true
    ports:
      - 3000:3000

  redis:
    image: "redis"
    container_name: redis
    networks:
      - todo-net

networks:
  todo-net: {}

อ่านไฟล์นี้เป็นสี่ส่วน

สไลด์หน้า 26 ยังใช้ไฟล์เดียวกันนี้อธิบายอีกมุมหนึ่ง คือระบายสีแบ่งเป็นสี่ชั้น — front-end, back-end, database และ network — แล้วชี้ว่าเลข version ของแต่ละบริการอยู่ตรงไหน ประเด็นคือ ไฟล์เดียวบอกได้ทั้งหมดว่าระบบนี้ประกอบด้วยอะไร รุ่นไหน ต่อกันยังไง

เวลาอ่านสไลด์หน้านั้น ให้ดูที่ตัวบริการ ไม่ใช่ลำดับของป้าย — ในระบบนี้ webapp คือ front-end (หน้าเว็บที่เบราว์เซอร์เปิด) และ todo คือ back-end (REST API)

ได้อะไรจากการใช้ container กับ microservices

สไลด์หน้า 49 สรุปสี่ข้อ

• deploy ง่ายขึ้น โดยเฉพาะเมื่อมีหลายสภาพแวดล้อม — dev, test, production ใช้ image ตัวเดียวกัน
• ต่อสายกันได้ด้วยโปรแกรม (programmable connectivity) — เครือข่ายเป็นบรรทัดในไฟล์ ไม่ใช่การไปตั้งค่าที่อุปกรณ์
• จัดการ version ของบริการได้ — รัน todo release-1.3 ให้ผู้ใช้จริง ขณะที่ทดสอบ release-2.1 อยู่ข้าง ๆ ในเวลาเดียวกัน
• ควบคุม version ของโครงสร้างพื้นฐานได้ — compose file อยู่ใน git ถ้า release-2 มีปัญหา ก็ย้อนไฟล์กลับไป release-1 แล้วสั่งขึ้นใหม่

ข้อสุดท้ายคือความหมายตรงตัวของคำว่า software-defined ที่คาบแรกพูดถึง — โครงสร้างพื้นฐานกลายเป็นไฟล์ข้อความที่ย้อน version ได้เหมือนโค้ด

docker compose exec redis redis-cli

ส่วนที่ 3 — สถาปัตยกรรม microservices

ปัญหาที่โผล่มาเมื่อบริการเพิ่มขึ้น

ระบบ todo เพิ่ม Notification Service เข้ามาอีกตัว (พอร์ต 9000) ตอนนี้มีสี่ชิ้น — webapp, todo, notification, redis

แต่ปัญหาไม่ได้อยู่ที่จำนวน ปัญหาอยู่ที่ เบราว์เซอร์ต้องรู้จักที่อยู่ของทุกบริการ

เพิ่มบริการที่สี่ ที่ห้า ที่หก ก็ต้องเพิ่มที่อยู่ในโค้ดฝั่ง client ทุกครั้ง แล้วต้องปล่อยแอปมือถือใหม่ทุกครั้งด้วย

ปัญหาเดียวกันนี้ในระบบขนาดจริง

สไลด์ยกตัวอย่างระบบแบบ Grab หรือ Uber ที่

• มีทั้งแอปมือถือและเว็บ
• ต่อกับบริการภายนอกหลายเจ้า — Twilio (บริการโทรศัพท์และ SMS) สำหรับเสียง, SendGrid (บริการส่งอีเมล) สำหรับอีเมล, Stripe (บริการรับชำระเงิน) สำหรับการจ่ายเงิน
• และตอนนี้ระบบเดิมที่เป็น monolith เริ่มไปต่อไม่ไหว

พอแยกออกมาก็ได้ประมาณหกบริการ — Passenger Management, Driver Management, Trip Management, Billing, Payments, Notification โดยตัวที่ต่อกับโลกภายนอกจะมี Adapter (ตัวแปลงที่คั่นระหว่างบริการของเรากับ API ของเจ้าอื่น) ของตัวเอง เช่น Billing มี Stripe Adapter และ Notification มีทั้ง Twilio Adapter และ SendGrid Adapter

สไลด์หน้า 57 ยังแสดงรายละเอียดที่ควรสังเกตอีกอย่าง: ไม่ใช่ทุก client ที่เข้าทาง gateway แอปมือถือยิงผ่าน API Gateway ส่วนเบราว์เซอร์บนคอมพิวเตอร์เปิดหน้าเว็บ (Passenger Web UI, Driver Web UI) ตรง ๆ แล้วให้หน้าเว็บนั้นเป็นฝ่ายเรียกบริการต่อ

เหตุผลคือหน้าเว็บเป็นของเราเอง ปล่อยใหม่เมื่อไหร่ก็ได้ ต่างจากแอปมือถือที่ผู้ใช้ต้องกดอัปเดตเอง — สิ่งที่เปลี่ยนยากที่สุดจึงเป็นสิ่งที่ต้องกันไว้หลัง gateway มากที่สุด

หนึ่งหน้าจอ หลายการเรียก

สไลด์หน้า 55 ใช้หน้ารายละเอียดสินค้าของ Amazon เป็นตัวอย่าง หน้าจอเดียวนั้นต้องดึงข้อมูลจากหกบริการ

1. Order History — เคยซื้อไปแล้วหรือยัง
2. Reviews — คะแนนและรีวิว
3. Basic Product Info — ชื่อ ราคา รูป
4. Recommendation — คนที่ซื้อสิ่งนี้ยังซื้ออะไรอีก
5. Inventory — เหลือกี่ชิ้น
6. Shipping — ส่งถึงเมื่อไหร่

ถ้าให้แอปมือถือยิงหกครั้งเอง จะเจอสามปัญหาพร้อมกัน: ต้องรู้ที่อยู่หกแห่ง, เสียเวลาไป-กลับหกรอบบนเครือข่ายมือถือที่ช้า, และถ้าบริการหนึ่งเปลี่ยนที่อยู่ ต้องปล่อยแอปใหม่

ทางออก: API Gateway

รูปแบบนี้เรียกว่า Façade Pattern (รูปแบบด้านหน้าอาคาร — ซ่อนความยุ่งข้างในไว้หลังหน้าตาเรียบ ๆ อันเดียว) ในโลกของ microservices ตัวที่ทำหน้าที่นี้คือ API Gateway (ประตูเดียวที่รับคำขอจากภายนอกแล้วส่งต่อให้บริการข้างใน)

สไลด์หน้า 58 ระบุว่า gateway ทำอะไรให้บ้าง

ห่อโครงสร้างภายในของแอปไว้ เป็นข้อหลัก และทำให้ทำอีกห้าอย่างได้ง่ายขึ้นด้วย

กระจายโหลด

สไลด์หน้า 59 กับ 60 วางคู่กันเพื่อให้เห็นความต่าง: หน้าแรกมี Service-1 หนึ่งตัว หน้าที่สอง Service-1 กลายเป็นสามสำเนา

สิ่งที่ ไม่เปลี่ยน คือฝั่ง client — มันยังยิงมาที่ gateway ที่อยู่เดิม ไม่รู้เลยว่าข้างในมีกี่ตัว

จัดการเมื่อคนล้น

หน้า 61 วาดคำขอสี่อันวิ่งเข้ามาหา Service-1 พร้อมกัน แต่กำลังรับได้แค่สอง gateway จึงตอบ OK ให้สอง และให้อีกสอง WAIT

Service Discovery: ปัญหาที่อยู่ไม่นิ่ง

จะเขียนที่อยู่เหล่านี้ลงไฟล์ตั้งค่าไม่ได้ ต้องมีคน จดไว้และให้ถาม สิ่งนั้นคือ Service Registry (ทะเบียนบริการ ที่จดว่าตอนนี้บริการไหนอยู่ที่ไหนบ้าง)

บริการทุกตัวมี Registry Client (ส่วนเล็ก ๆ ในบริการที่คอยแจ้งทะเบียนว่าตัวเองยังอยู่) คอยลงทะเบียนตัวเองไว้ จากนั้นมีสองวิธีที่จะใช้ทะเบียนนี้

แบบที่ 1 — Client-Side Discovery

client เป็นคนถามเอง

1. client ถาม registry ว่า service นี้อยู่ที่ไหนบ้าง
2. registry ตอบมาเป็นรายการที่อยู่
3. client เลือกเองว่าจะยิงไปตัวไหน แล้วเรียกตรง

ข้อดี: ไม่มีตัวกลางเพิ่ม จึงเร็วกว่าและมีจุดที่จะล่มน้อยกว่า

ข้อเสีย: ทุก client ต้องมีโค้ดส่วนนี้ ถ้ามี client สามภาษา ต้องเขียนสามครั้ง และเวลาจะเปลี่ยนวิธีเลือก ต้องปล่อย client ใหม่ทุกตัว

แบบที่ 2 — Server-Side Discovery

load balancer เป็นคนถามให้

1. client ยิงคำขอไปที่ load balancer ที่อยู่คงที่
2. load balancer ถาม registry เอง
3. load balancer เลือกตัวปลายทางแล้วส่งต่อ

ข้อดี: client ไม่ต้องรู้อะไรเลย ยิงที่เดิมเสมอ เปลี่ยนวิธีเลือกได้โดยไม่แตะ client

ข้อเสีย: มีชิ้นส่วนเพิ่มหนึ่งชิ้นที่ต้องดูแล และถ้ามันล่มก็ล่มทั้งหมด

สไลด์ยกตัวอย่างของจริงว่า consul + consul-template + nginx และ Kubernetes ในคาบหน้าก็ใช้แนวนี้

ส่วนประกอบของสถาปัตยกรรม microservices

สไลด์หน้า 65 รวบทุกอย่างเป็นรายการเดียว ใช้เป็นเช็กลิสต์ได้

ทำ API Gateway ของจริงด้วย nginx

เป้าหมายคือเปลี่ยนจาก "เบราว์เซอร์ต้องรู้จักพอร์ต 8000 และ 9000" เป็น "เบราว์เซอร์รู้จักแค่พอร์ต 8000 ที่เดียว"

ทำไมต้อง nginx

nginx (เว็บเซิร์ฟเวอร์โอเพนซอร์สที่ใช้เป็น reverse proxy ได้) เป็นตัวเลือกที่สไลด์ใช้ เพราะ

• ใช้เป็น Reverse Proxy (ตัวรับคำขอแทนเซิร์ฟเวอร์จริงแล้วส่งต่อให้ข้างหลัง) ได้
• เร็วและเสถียร
• ตั้งค่าง่าย
• กินทรัพยากรน้อย
• รองรับ load balancing

ในทางปฏิบัติ nginx ตัวเดียวทำหน้าที่ได้หลายอย่างพร้อมกัน — เป็นทั้ง API gateway, cache (ที่พักข้อมูลไว้ตอบซ้ำโดยไม่ต้องถามข้างหลัง), load balancer และ WAF (Web Application Firewall) (ตัวกรองคำขอที่เป็นการโจมตี)

ไฟล์ตั้งค่า

ไฟล์เดียวนี้คือหัวใจของทั้งเรื่อง ชื่อ api.conf

server {
    listen       8000;
    server_name  localhost;

    location /todo/ {
        proxy_pass http://todo:8000/;
    }

    location /notification/ {
        proxy_pass http://notification:9000/;
    }
}

อ่านทีละบรรทัด

แพ็ก gateway เป็น image

FROM nginx
COPY api.conf /etc/nginx/conf.d
ENTRYPOINT ["/docker-entrypoint.sh"]
EXPOSE 8000
STOPSIGNAL SIGTERM
CMD ["nginx", "-g", "daemon off;"]

ทั้งหมดที่ทำคือ ก็อป api.conf เข้าไปในโฟลเดอร์ที่ nginx อ่าน ที่เหลือคือค่าปริยายของ image nginx เอง

จุดที่ควรสังเกตคือ daemon off; — ปกติ nginx จะแยกตัวเองไปรันเบื้องหลังแล้วโปรเซสแรกจบ ซึ่งจะทำให้ container ดับทันที การสั่ง daemon off บังคับให้ nginx อยู่เป็นโปรเซสหน้า container จึงอยู่ต่อได้

STOPSIGNAL SIGTERM บอก Docker ว่าเวลาจะหยุด container ให้ส่งสัญญาณอะไรไปให้โปรแกรมเก็บของก่อนตาย

สั่งทั้งระบบขึ้น

ระบบตอนนี้มีห้าชิ้น ทั้งหมดอยู่บน todo-net

docker network create todo-net

docker run -d --rm --name redis --network todo-net redis

docker run -d -t --rm --name notification --network todo-net \
  --env REDIS_HOST=redis todo-notification:release-1.1

docker run -d --rm --name todo --network todo-net --env REDIS_HOST=redis \
  --env NOTIFICATION_HOST=notification todo:release-3

docker run -d --rm --name api --network todo-net -p 8000:8000 api

docker run -d -t --rm --name webapp --network todo-net \
  -p 3000:3000 todo-webapp:release-3.1

สังเกตสามอย่างในชุดคำสั่งนี้

1. มีแค่สอง container ที่เปิดพอร์ตออก host — api (8000) และ webapp (3000) ส่วน todo, notification, redis ไม่เปิดเลย เพราะไม่มีใครควรเรียกถึงจากข้างนอก
2. ที่อยู่ของทุกอย่างส่งผ่าน --env — REDIS_HOST=redis, NOTIFICATION_HOST=notification ไม่มีเลข IP โผล่ในคำสั่งไหนเลยสักอัน
3. ลำดับสำคัญ — สร้าง redis ก่อน แล้วค่อย notification แล้วค่อย todo เพราะตัวหลังต้องการตัวหน้า

services:
  redis:
    image: "redis:7.0.12"
    networks: [todo-net]

  notification:
    image: "todo-notification:release-1.1"
    environment:
      REDIS_HOST: redis
    networks: [todo-net]

  todo:
    image: "todo:release-3"
    environment:
      REDIS_HOST: redis
      NOTIFICATION_HOST: notification
    networks: [todo-net]

  api:
    image: "api"
    ports:
      - 8000:8000
    networks: [todo-net]

  webapp:
    image: "todo-webapp:release-3.1"
    stdin_open: true
    tty: true
    ports:
      - 3000:3000
    networks: [todo-net]

networks:
  todo-net: {}

ได้อะไรจาก deployment orchestration

สไลด์หน้าสุดท้ายสรุปห้าข้อ ซึ่งอ่านแล้วจะเห็นว่ามันตอบปัญหาที่เจอมาทั้งคาบพอดี