Microservice có phải là miền đất hứa?

    Thuật ngữ Microservice đã không còn xa lạ trong việc triển khai các ứng dụng và hệ thống phần mềm trong nhiều năm trở lại đây, Microservice sẽ là lựa chọn hàng đầu của developer khi bắt đầu xây dựng một hệ thống mới. Và cũng là mục tiêu chuyển đổi cho nhiều hệ thống monolithic đang hoạt động kém hiệu quả.

//TODO link đến bài chuyển đổi microservice in action, lick vào chỗ bôi đậm bên trên

    Trong bối cảnh hiện nay, các ứng dụng ngày càng trở nên phức tạp, hệ sinh thái đã trở nên rất đa dạng về thiết bị và các phương thức giao tiếp, developer ngày càng phải xử lý những vấn đề phức tạp và business thay đổi liên tục. Ứng dụng Monolithic khi vừa phát triển có lẽ sẽ không có vấn đề gì, nhưng càng phát triển sẽ càng bộc lộ những nhược điểm mà nếu không được đánh giá để chuyển đổi kịp thời sang microsevice thì đến một thời điểm doanh nghiệp sẽ nhận ra hệ thống hiện tại không thể đáp ứng được business. Nhưng microservice có phải chỉ có những hứa hẹn như cách mà chúng ta vẫn nghe về nó. Bài viết này sẽ đi vào những thách thức mà nhà phát triển sẽ phải đối mặt trước khi có thể đạt được những giá trị mà microservice mang lại. 

Microservice và Monolithic

    Ưu điểm lớn nhất của monolithic là tính dễ triển khai, chi phí thấp, phát triển nhanh khi ở quy mô nhỏ, còn với Microservice ưu điểm sẽ là tính linh hoạt trong việc thay đổi và mở rộng. Nhà phát triển cần bỏ công sức ra nhiều hơn để phát triển, bảo trì và vận hành hệ thống microservice so với một hệ thống monolithic có cùng tính năng. 

    Những giá trị microservice mang đến thật sự đáng giá, ví dụ như khả năng phục hồi, khả năng chịu lỗi, khả năng co giãn đáp ứng tải. Nhưng những điều này không phải tự nhiên mà có. Câu chuyện với Microservice không đơn giản như cài đặt một framework, vì là kiến trúc phần mềm, Microservice được mô tả bằng các pattern, concept và principle. Và để đạt được những giá trị của microservice đòi hỏi nhà phát triển vừa triển khai theo các concept nhưng cũng phải cân đối chi phí cho việc phát triển theo từng giai đoạn.

Lợi ích của Microservice

Cùng điểm qua một số ưu điểm của microservice trước khi đi vào chi phí

• Những dịch vụ có thể rất đơn giản, tập trung vào một số business nhất định
• Hệ thống xây dựng theo hướng loosely coupling, xoay quanh business
• Nhiều nhà phát triển hoặc các team khác nhau có thể đồng thời triển khai các tính năng tương đối độc lập với nhau
• Phù hợp với nhu cầu delivery liên tục, cho phép release trong khi giữ phần còn lại của hệ thống vẫn ổn định

Chi phí phát triển

Microservice cần rất nhiều chi phí vận hành

   Thông thường một ứng dụng trải qua rất nhiều các phase trước khi được publish hoàn toàn. Mỗi service phải trải qua build, test, deploy and run. Mỗi dịch vụ có thể được viết bằng các ngôn ngữ và chạy trên các môi trường/ hệ điều hành khác nhau, các kịch bản triển khai CICD, và các dependency cũng có thể khác nhau.

    Mỗi ứng dụng lại cần được triển khai theo cụm(clustering) để đáp ứng khả năng chịu lỗi và phục hồi, dẫn đến x2, x3 số lượng runtime instance so với số lượng dịch vụ ban đầu. Nếu hệ thống có 15 service, số lượng runtime instance có thể lên tới 30-50. Cộng thêm với các thành phần Load balancer và Message broker, hệ thống đã trở nên khá lớn nếu so với ứng dụng monolithic cùng chức năng.

    Do hệ thống bị phân tán , việc monitoring và tracing cũng cần được thêm vào để đảm bảo hệ thống hoạt động ổn đinh. Tránh tình trạng deadlock, hết dung lượng lưu trữ, compute bị quá tải...hay làm sao để biết được dịch vụ nào đang bị quá tải hoặc bị ngừng hoạt động để đưa ra quyết định phù hợp, hoặc làm sao để tracing được data/bug khi thực hiện một chức năng cross qua nhiều service và kênh messaging. Để ghi lại và truy vấn được log trong 30-50 instance cần một lượng tài nguyên không hề nhỏ.

    Hiện tại đã có nhiều giải pháp đáp ứng các quá trình phát triển và triển khai các microservice, nhưng thường những ứng dụng này chỉ đáp ứng một phần các công việc cần làm . Gần như nhà phát triển sẽ cần triển khai hệ thống ở một mức độ nhất định trước khi có thể bắt tay vào code business.

Yêu cầu kĩ năng DevOps

Một hệ thống Microservice thường được triển khai qua một Container Engine/ Container Orchestration như Docker, Docker swarm, K8S, Openshift... Những công nghệ này yêu cầu kiến thức về docker, container, hệ điều hành và commandline, chưa kể đến kiến thức về mạng, storage, environment thậm chí các kiến thức nâng cao hơn về ảo hóa, clustering của mỗi công nghệ đặc thù. Hệ thống được tạo nên từ nhiều dịch vụ nhỏ, nên quá trình CICD là không thể thiếu để quá trình triển khai và tích hợp được tự động. Những kiến thức trên khá xa lạ với các developer chuyên về business như Frontend hay Backend, nên hệ thống Microservice yêu cầu kĩ năng về DevOps đáng kể

Interface Giao tiếp giữa các dịch vụ không rõ ràng

Vì hệ thống được chia nhỏ ra thành cách thành phần riêng biệt có thể cả về hướng kĩ thuật hoặc hướng theo domain business, các dịch vụ này cũng có thể được thực hiện bởi những cá nhân hay team khác nhau, dẫn đến việc hợp đồng cùng với nhau để định nghĩa interface giao tiếp giữa các service-service hoặc service-message broker trở nên phức tạp và không ổn định nếu giữa các team/ cá nhân không tuân thủ theo các rule về mặt giao tiếp. Function sẽ bị break nếu một bên thay đổi kiểu dữ liệu hoặc một dữ liệu mandatory không được đáp ứng giữa các service. Một số chuẩn giao tiếp hoặc công nghệ hỗ trợ cho chuẩn hóa format API và giữ liệu như OpenAPI hay Schema registry đã giúp ích rất nhiều cho việc collab giữa các dịch vụ, nhưng về bản chất nhà phát triển cần có các biện pháp để deal với vấn đề này.

Multiply Effort

    Hệ thống microservice có xu hướng triển khai hầu hết các dịch vụ chính trên cùng một công nghệ hoặc ngôn ngữ để giảm effort phát triển, nhưng ngay cả khi đã triển khai trên cùng một công nghệ thì các dịch vụ cũng thường được lưu trữ code hoàn toàn tách biệt về phạm vi project code và dependency.

Nhà phát triển thường xuyên phải đối mặt với vấn đề duplicate các đoạn code hoặc chức năng trên các service khác nhau, thậm chí ngay cả khi bắt đầu một dịch vụ mới, các cấu hình hệ thống, environment cũng thường được sử dụng lại trên các dịch vụ, các function util, secret, apikey... Điều gì sẽ xảy ra khi một đoạn code hay chức năng global cần được update tính năng hoặc fix bug, nhà phát triển cần đi thực hiện thay đổi đó ở tất cả các dịch vụ đang sử dụng. Vì đặc tính loose coupling của microservice nên việc duplicate các model hay code giữa các service là điều không thể tránh khỏi, nhưng cũng cần được tối ưu để giảm chi phí và rủi ro cho việc maintain hệ thống.

Xử lý hệ thống phân tán phức tạp

Microservice triển khai trên một hệ thống phân tán, các service thậm chí còn không cùng nằm trên một server, đây cũng chính là nguyên do dẫn đến rất nhiều vấn đề của microservice mà nếu ở hệ thống monolithic thậm chí chúng ta còn chưa nghe tới. Các vấn đề có thể kể đến như khả năng chịu lỗi, độ trễ của mạng, xử lý bất đồng bộ, transaction cross qua nhiều service, version của ứng dụng, tracing dữ liệu, khả năng tương thích ngược, cấu hình tập trung...

• Khả năng chịu lỗi: Microservice cần có khả năng chịu lỗi khi có một thành phần trong hệ thống không hoạt động và đảm bảo business không bị ảnh hưởng khi có một dịch vụ bị downtime hoặc xảy ra lỗi trong giao tiếp
• Độ trễ của network: Với càng nhiều microservice, nguy cơ độ trễ của function càng lớn, vấn đề này rất quan trọng với các ứng dụng yêu cầu tốc độ cao và ổn định như chứng khoán, financial
• Xử lý bất đồng bộ: Trong hệ thống có thể có những function không thể nào nhận được đáp ứng ngay lập tức, vậy hệ thống lại cần có cơ chế để bên request có thể thực sự nhận biết được kết quả của một request đã được đáp ứng thực sự.
• Transaction cross qua nhiều dịch vụ: Đây là vấn đề thực sự quan trọng, Data consistency luôn là vấn đề quan trọng trong bất cứ hệ thống nào. Có lỗi trên một ứng dụng monolithic sẽ dễ dàng được giải quyết hơn do các framework hầu hết đã hỗ trợ Transactional trên các function khi thực thi. Nhưng điều này không thể lặp lại trên microservice, do các ứng dụng có nhu cầu gọi đến nhau để thực thi một business function, chưa kể đến các kênh giao tiếp khác Send and forget (messaging), dẫn đến các chức năng hoặc dữ liệu không thể rollback theo cách truyền thống.
• Version của ứng dụng: Việc collab giữa các team yêu cầu sự thống nhất về mặt interface giao tiếp và chức năng. Làm sao để biết một business function trong release mới đang cần code của những dịch vụ nào, version nào của dịch vụ đó, và nhu cầu rollback cả hệ thống nữa. 
• Tracing dữ liệu: Việc debug trên hệ thống microservice không đầy đủ là khá khó khăn, nếu một function cross qua nhiều service và mỗi service chạy trên một vài instance. Điều này lại yêu cầu một hệ thống loging tập trung nữa.
• Khả năng tương thích ngược: Các ứng dụng khi phát triển cần được quản lý các version và thay đổi interface một cách cần trọng, cân nhắc đến khả năng tương thích ngược với các hệ thống hiện tại. Thận trọng trong các thay đổi về request/response hoặc các bussiness code. Bạn có thể phát triển thêm một tính năng những sẽ break business hiện tại.
• Centralize configuration: Khi hệ thống phân tán mà không có giải pháp cho việc centralize các configuration, nhà phát triển sẽ phải thường xuyên thay đổi các config một các thủ công và trên nhiều dịch vụ. Việc này khá mất effort và không đảm bảo tính chính xác/ ổn định của hệ thống

Những vấn đề này sẽ được đề cập chi tiết hơn trong các bài viết sau.

Khả năng kiểm thử

Do có nhiều dịch vụ nên việc kiểm thử trở nên khó khăn và tốn effort trên cả unit test/ manual test/ auto test/ intergration test. Thậm chí còn trở nên khó khăn hơn nữa với các chức năng sử dụng bất đồng bộ(async/callback) hoặc messaging(publish/subscribe).

Handle multi instance

Nhà phát triển cần chú ý tới khả năng multi instance có ảnh hưởng đến các chức năng vốn có của các dịch vụ hay không. Nếu lúc đầu các dịch vụ luôn chỉ có 1 instance, nhưng không chắc chắn khi tăng số  replica , mọi business sẽ hoạt động ổn định. Lấy ví dụ với các chức năng về cron-job hoặc subscribe messaging thường chỉ có nhu cầu được trigger/execute 1 lần trên cả hệ thống, nhưng với multi instance, các chức năng này cũng sẽ được repeat hoặc chạy song song nếu không thêm vào các kĩ thuật để xử lý. 

Kết

Trên đây là những khó khăn mà tôi đã gặp phải trong quá trình phát triển hệ thống với microservice, các vấn đề sẽ được phân tích và thảo luận hướng giải quyết trong các bài viết tiếp theo. Tuy có nhiều khó khăn, thách thức nhưng những gì Microservice mang lại là rất đáng giá. Với cách tiếp cận đúng đắn khi nhìn vào cả cơ hội và thách thức của Microservice, tôi hi vọng sẽ giúp cho nhà phát triển có cái nhìn toàn diện hơn và tránh được những sai lầm trong quá trình phát triển microservice.

Peace! 

Tác giả: Ethanol Tran

DNS hoạt động như thế nào? 2

 

Mở đầu

Nhiều năm trước đây, khi mới bước chân vào nghề lập trình web, lần đầu tiên chạy được một ứng dụng web trên địa chỉ localhost:8080 và 127.0.0.1:3000, mình đã tự hỏi:

"Máy tính kết nối tới mạng internet qua địa chỉ IP các thứ, rồi bình thường mình vẫn truy cập web bằng tên miền website, vậy sao mà cái tên website kia lại dẫn tới cái máy chứa trang web được? bla bla..".

Trong bài viết này chúng ta cùng đi tìm hiểu IP, Domain, DNS là gì và chúng liên quan đến nhau như thế nào, và làm cách nào mà trình duyệt có thể request đến đúng máy tính chứa nội dung cần truy cập.

IP và Domain

Thiết bị trong một mạng máy tính sử dụng giao thức Internet( Internet Protocol) sẽ được cung cấp một địa chỉ IP, địa chỉ IP tương đương với định danh của thiết bị trong network, giúp phân biệt giữa các máy tính khác nhau. Địa chỉ IP là một dãy số có dạng xxx.xxx.xxx.xxx

 Tương tự như vậy, với mạng Internet toàn cầu, các máy tính cũng được định danh bằng các địa chỉ IP. Nhưng con người làm sao nhớ được các con số vô nghĩa, chưa kể dãy số còn dài thế kia, vậy nên chúng ta sử dụng các từ gợi nhớ có nghĩa. ví dụ:

- dichvucong.gov.vn

- vi.wikipedia.org

- mail.google.com

- dantri.com

- sunteco.vn

Các tên gợi nhớ này được gọi là tên miền(Domain) và được đặt theo một số quy tắc nhất định.

DNS(Domain name system) sẽ gắn kết hai phần này lại với nhau và bằng cách nào đó khi bạn truy cập tên miền bạn sẽ được chuyển đến đúng địa chỉ IP cần đến. Đó là cách mà DNS hoạt động.

Hành trình từ Domain đến IP

Chúng ta vừa hiểu một cách sơ lược cách hoạt động của DNS, thử tham gia hành trình truy cập một trang web xem sao.

23h PM 

--- Browser and OS---

Human: Typing...

Browser: - Ể có request mới nè: zzz.com, cái trang web gì mà khó hiểu, đợi tí bạn ôi, để tôi xem có thông tin về trang này ko, trước khi tôi hỏi OS, lão đấy khó chịu lắm... Haizza, ko có rồi, đợi tí nhé.

- Hi OS, có đấy ko, tui nhờ tí, tôi có thể tìm zzz.com ở đâu

OS: Bruh bruh, System is updating...

Browser: - Giúp tí i

OS: (Checking now...) -ko thấy nhé, nhưng tôi biết phải hỏi ai để tìm. RESOLVERRRR!!!!

Đến đây ta đều thấy Trình duyệt và hệ điều hành đều tìm kiếm trong cache nhưng không thấy, OS sẽ tiếp tục request đến Resolver

--- Resolver and Root server ----

Resolver hay còn gọi là DNS recursive resolver. Resolver thường được cung cấp bởi ISP(Internet Service Provider) - Nhà cung cấp dịch vụ Internet. Tất cả các nhà cung cấp dịch vụ đều biết: Làm sao để tìm được Root server. Root server lại biết nơi nào để tìm được .COM TLD server. TLD là viết tắt của Top-Level Domain.

...Hộp thư đến có thư mới...loạt soạt

Resolver: Request mới đến, tuyệt vời, zzz.com, ok để xem nào... ko có trong cache rồi. Đi hỏi Root server thôi.

Root server: Người tiếp theo. Tôi giúp gì được cho bạn.

Resolver: Hi root, tôi đang tìm địa chỉ của zzz.com. Bạn có thể giúp tôi ko?

Root server: Sorry nhé, tôi ko biết địa chỉ của zzz.com, nhưng tôi biết .COM Top-level domain server ở đâu đấy!

Resolver: Ok thanks kiu, trước khi đi tiếp, tôi cache lại phát đã.

Root server này là 1 trong 13 máy chủ Root Name. Root server nằm trên đỉnh của hệ thống phân cấp DNS. Chúng được đặt khắp thế giới và được điều hành bởi 12 tổ chức độc lập khác nhau. Chúng được đặt tên theo định dạng [chữ cái].root-servers.net , các chữ cái được đặt từ a đến m. Điều này không có nghĩa là chỉ có 13 máy chủ vật lý để phục vụ cả thế giới, trên thực tế mỗi tổ chức sẽ cung cấp dịch vụ trên nhiều server vật lý phân tán.

--- tại Top-level Domain .COM ---

Resolver: Tôi không ngại đến đây, tôi chỉ cần một lý do thôi.

.com TLD: WHAT tờ hell??? bad joke, dude!

Resolve: Hợ, sorry, tôi đang tìm zzz.com, cho tôi biết nó ở đâu được ko?

.com TLD: huhm, câu hỏi hay đấy!

Sự sắp xếp của hầu hết các top-level domains thuộc về Internet Coporation for Assigned Names and Number (ICANN). .COM TLD là một trong những cái tên được tạo ra đầu tiên năm 1985. Ngày nay nó cũng trở thành TLD lớn nhất. Một vài loại TLD khác có thể kể đến như 

• Tên quốc gia (.vn, .uk), 
• TLD viết bằng ngôn ngữ native locallization(tiếng trung, tiếng arap)
• Những tên phổ biến khác như. net,. org, .edu
• TLD hạ tầng: .ARPA, hầu hết dùng cho reverse DNS lookups(Tra cứu tên miền từ IP)

Ngày nay có càng nhiều hơn các TLD được tạo ra. Giờ thì quay trở lại với câu hỏi của Resolver 

.com TLD: Cache searching...Tôi sợ là tôi ko biết IP của zzz.com ở đâu, nhưng tôi tìm thấy name server  của zzz.com đấy (Đưa cho mảnh giấy)

Resolver: Tuyệt vời,Cảm ơn nhé, cache phát nữa. Khoan đã, sao .com có thể chỉ mình tới name server nào nhỉ???

Vậy là .Com TLD đã tìm thấy name servers của zzz.com là aleza.cloudflare.com, name server hay còn gọi là authoritative name server. Khi một domain được thanh toán, Domain Registra (Nhà cung cấp tên miền) sẽ lưu trữ tên miền này và thông báo tới TLD về name server có thẩm quyền của mỗi tên miền. Từ đã, Resolve đang đi phân giải tên miền mà lại nhận được một tên miền nữa là sao? Trên thực tế có thêm những thông tin bổ sung đi kèm với name server, Resolve nhận được ít nhất một địa chỉ IP với mỗi name server, vậy nên Resolver có thể tới chính xác được máy chủ của name server.

aleza.cloudflare.com - 197.246.15.51

bzeta.cloudflare.com - 51.32.246.54

--- Last trip, tại name server--------

aleza.cloudflare.com: Người tiếp theo 

Resolver: Thank god, tôi đã đi một chuyến dài, .com nói tôi tới đây, đằng ấy cho tôi biết địa chỉ IP của zzz.com được ko

aleza.cloudflare.com: Bạn tìm đúng người rồi đấy, tôi chính là name server của zzz.com đây, thực ra có một vài người giống tôi nữa cũng có thể cung cấp IP của zzz.com nữa, vd bzeta.cloudflare.com, đề phòng trường hợp 1 trong chúng tôi ko thể phục vụ. Ok giải thích thế đủ rồi, IP của zzz.com đây: 49.53.63.69

Resolver: Hả?

aleza.cloudflare.com: IP của zzz.com đấy gì nữa 49.53.63.69

Resolver: Oh, thanks(Hí hoáy note).

Resolver: Phùuuu, về nhà thôi

--- Tại Homie computer---

OS: Did you finish? Resolver. Tôi đợi ông hơi lâu rồi đấy (5ms)

Resolver: Hi OS, Câu trả lời đây, IP của zzz.com là 49.53.63.69

OS: Được ấy nhể, nói chuyện sau nhé, tôi giải quyết công việc đã.

OS: Hey Browser, đây là IP của zzz.com, làm gì làm đi.

Browser: Ồ, thanks. Finally!

Connecting...to 49.53.63.69

49.53.63.69: Sure, here your website.

Human:  (Cuộn chuột, click, click...)

Kết 

Qúa trình phân giải từ Domain sang IP có thể tóm tắt bằng sơ đồ sau.

Hi vọng với hành trình và câu chuyện của các nhân vật giả tưởng trên đây có thể giúp các bạn hiểu thêm về nguyên lý hoạt động của IP, Domain và DNS.

Thanks for watching!

Thay đổi cấu hình ứng dụng web(Angular/ Reactjs) bằng biến môi trường mà không cần rebuild

Mở đầu

   Process triển khai phổ biến hiện nay của các  Single Page Application (SPA) hiện nay là Code => Build => Package => Deploy. Trong đó Build phase sẽ biên dịch code từ frame work thành code HTML, CSS, JS  mà trình duyệt có thể hiểu được. Package phase đóng gói code đã được biên dịch vào một Web server image(Nginx, Apache) và sau đó Deploy phase sẽ triển khai Image lên các Container Engine Platform(Docker, K8S, Aws ECS, Sun Spinner...).

    Trong phase Build , build command với tham số biến môi trường, các file config chứa biến môi trường tương ứng sẽ được biên dịch cùng với source code. Cách làm truyền thống này đáp ứng được hầu hết các yêu cầu trong quá trình phát triển nhưng vẫn tồn tại một số hạn chế:

• Tiêu tốn thời gian build không cần thiết: Do mỗi môi trường yêu cầu một phase build khác nhau mặc dù Source code sau khi biên dịch không có gì khác nhau ngoài các biến môi trường. Trên thực tế các dự án mình đã trải qua, quá trình build production của ứng dụng Angular mất khoảng 15 phút, thời gian build của react js thậm chí còn lên tới 30 phút hoặc hơn nữa. Thời gian build có thể thay đổi phụ thuộc khối  lượng source code và cách optimize, nhưng rõ ràng những con số trên đáng để cân nhắc một giải pháp tối ưu hơn cho thời gian triển khai CICD. 
• Không đủ linh hoạt cho các bài toán Cloud solution, dynamic config: Các bài toán về ứng dụng cloud, multi tenant sẽ không khả thi nếu Source code sau khi build chỉ có thể làm việc với một bộ configuration duy nhất
• Vấn đề Security: Do dữ liệu cấu hình là một phần của source code, Mỗi thành viên đều có thể truy cập config của tất cả các môi trường, dẫn đến rủi ro về bảo mật và vận hành .

Các ứng dụng backend cũng gặp vấn đề này nhưng được giải quyết đơn giản bằng native Environment của phía server, các biến môi trường có thể được inject qua phase Package nên một source code có thể làm việc với nhiều cấu hình khác nhau.

Cách giải quyết

Vậy giải pháp sẽ là phải làm sao để một bộ source code sau khi build có thể được inject các biến môi trường khác nhau tương tự như cách ứng dụng backend hoạt động. Sau đây là cách giải quyết vấn đề, nguyên lý chung này có thể áp dụng cho các web framework và ngôn ngữ khác nhau.

1. Chuẩn bị giải pháp cho phép ứng dụng đọc cấu hình từ một nguồn độc lập với source code(File, API)
2. Chỉnh sửa code của ứng dụng để thay thế các biến môi trường từ nguồn trên
3. Đảm bảo Cấu hình được load xong trước tiên, làm nguồn cho các render chức năng, giao diện về sau

Thực hành với Angular

Mặc định các file config tồn tại trong thư mục src/environments/ với format environment.<env name>.ts và chỉ dẫn build được đặt trong file angular.json. Với lệnh ng build --configuration=production Angular CLI sẽ thay thế file environment.ts bằng file environmen.prod.ts theo chỉ dẫn fileReplacement 

Và các file logic code sẽ import và sử dụng biến môi trường từ file environment.ts.

Ta sẽ bỏ qua các cài đặt mặc định của Angular để thực hiện giải pháp theo các nguyên lý đã nêu ở trên.

1. Tạo một file cấu hình JSON có các key giống với file environment.ts trong src folder. Ví dụ env.json
   
   
   
2. Cấu hình location của file env.json vào phần assets trong angular.json để webpack giữ nguyên file này như một file assets
3. Tạo một service để đọc cấu hình từ file env.json, lưu ý vị trí tương đối của Service này với file env.json
   
   
   
   
4. Đảm bảo dữ liệu config được load đầu tiên khi khởi động ứng dụng
5. Kết quả 
   
   
   
   
   
   
   

Vậy là ứng dụng đã đọc được nội dung từ một file hoặc từ một API độc lập. Nhưng từ từ đã, đến đây đã đạt được dự định ban đầu chưa, ta chưa thấy cách inject được giá trị configuration khác. Trên thực tế, sau khi tách file cấu hình ra khỏi phase Build là đã có thể giải quyết được vấn đề. Sau đây là một vài cách để thực hiện việc inject giá trị config.

1. Inject value vào file env.json trong phase Package của quá trình CICD(thay thế giá trị của file này)
2. Sử dụng API để lấy cấu hình từ phía backend không cần ghi đè file: Sử dụng API với các param đặc trưng cho phía client như IP, location, hostname... để làm parameter cho việc lấy cấu hình. Ví dụ một api với param /env?hostname=localhost:4200 sẽ trả về env với apiEndpoint là localhost:3000, hostname có thể lấy qua biến window.location  của trình duyệt.
3. Khi triển khai ứng dụng bằng các Container Engine Platform: các Engine này có hỗ trợ tính năng mount volume, ta chỉ cần cấu hình mount các file chứa biến môi trường tương ứng từ hệ thống quản lý biến môi trường của Container Engine thay thế vào vị trí file env.json bên trong container chứa source code.

Đọc thêm: 

Hướng dẫn cấu hình ConfigMap K8S

Hướng dẫn mount ConfigMap với Sun Spinner

Kết

    Với các thay đổi theo hướng dẫn ở trên, có thể triển khai ứng dụng web với các biến môi trường khác nhau gần như ngay lập tức, các sửa đổi biến môi trường cũng được apply gần như real time. 

    Tham khảo Sunteco Cloud để có thêm nhiều giải pháp cho hệ thống của bạn.

Microservice thực chiến - API as a service P1 - Project requirement and system architect

Mở đầu 

        Hi các bạn, sau khi bài viết trước nhận được khá nhiều sự quan tâm, mình quyết định sẽ tiếp tục việc chia sẻ trải nghiệm của mình với microservice cũng như mong muốn nhận được những góp ý từ phía mọi người. Nếu như bài viết trước cắt ngang vào việc chuyển đổi từ monolith sang microservice thì từ bài viết này mình sẽ bắt đầu một series về xây dựng các dự án từ mức độ ý tưởng/ requirement, thiết kế kiến trúc, coding và deploy xoay quanh kiến trúc micorservice, từ đó nhìn nhận các khó khăn trong quá trình phát triển dự án với kiến trúc microservice và hướng khắc phục. Các dự án có thể là các project cũ bản thân đã từng trải qua trong quá trình làm việc, các business phổ biến trên thị trường, hoặc nếu các bạn muốn mình làm về chủ đề nào thì để lại requirement dưới comment. 

Project Requirement

    Ban đầu ý tưởng của mình là làm một trang thương mại điện tử trên nền microservice, nhưng nghĩ lại thì để full flow với hệ sinh thái đầy đủ từ warehouse, product, order, khuyến mãi, shiping, accounting, shop, supplier ... sẽ là hơi over cho một sự bắt đầu. Vậy nên sau đó mình nghĩ sẽ làm một ứng dụng đơn giản hơn chút. Business của mình sẽ là application dạng API as a service - Cung cấp dịch vụ qua API. Để dễ hiểu hơn thì các bạn có thể thấy các dịch vụ của google dành cho nhà phát triển có rất nhiều dịch vụ dạng API as a service, ví dụ như các dịch vụ về bản đồ, notification, verify phone number. 

    Mô hình kinh doanh của ứng dụng đã có rồi, vậy sẽ phục vụ nhu cầu gì của thị trường bây giờ? Vài năm trước có một người em nhờ mình tư vấn về giải pháp xác định đơn vị hành chính(phường/ xã, quận/ huyện, tỉnh/ thành phố ) dựa trên input là location(longtitude, latitude). Use case ở đây là các thiết bị có hỗ trợ GPS sẽ gửi location về máy chủ, từ đó máy chủ cần detect  được location theo đơn vị hành chính để thực hiện các business tiếp theo. Ví dụ:

- Các thiết bị thông minh/IoT có kết nối wifi/GPS cần gửi các thông số thiết bị về máy chủ để hỗ trợ quá trình chăm sóc khách hàng, bảo hành. Đi kèm với các thông số là data về location, xác định được đơn vị hành chính mới có thể phân phối thông tin đến các bộ phận cskn, bảo hành ở đúng khu vực một cách tự động

- Các doanh nghiệp logistic cũng cần một mapping từ các văn phòng/ kho hàng của họ đến các địa điểm lấy hàng của khách đề điều chuyển resource một cách hợp lý.

Vậy là đã xác định được core business của dự án, cùng điểm qua một số specification:

• Business cung cấp khả năng xác định đơn vị hành chính(xã/phường- quận/huyện - tỉnh/ thành phố) từ vị trí GPS(*)
• Mô hình kinh doanh API as a service, khách hàng sẽ trả phí để để có một lượng request nhất định
• Hệ thống đo được lượng request của khách để giới hạn nếu đã hết quota
• Dịch vụ có khả năng tích hợp API vào hệ thống của khách hàng.

(*)Trong series bài viết này mình không đi sâu vào phần core function của sản phẩm mà trập trung vào cách triển khai và sự liên kết giữa các phần trong dự án. Phần core function của dự án mình sẽ lướt qua nhé, coi như đã có giải pháp cho phần đó rồi :))

Research

    Cùng lượn qua thị trường một chút trước khi bắt tay vào việc, đợt có làm cái dự án về công nghệ bản đồ nên mình cũng có hiểu biết chút về mảng này. Một vài bên có dịch vụ tương tự mình định làm là Google Map và Mapbox, sang bên đó tham khảo xem dịch vụ họ đang cung cấp như thế nào.

Google Map services

                                                                     Mapbox services

     Về cơ bản thì dịch vụ mình định làm khá giống geocoding của Google và Mapbox. Dịch vụ của họ support convert từ Geo location sang địa chỉ dạng text hoặc ngược lại

Đánh giá dùng thử dịch vụ

    Dữ liệu của google sát hơn với requirement mà mình vừa đề ra ở trên, có các trường dữ liệu rõ ràng phân chia theo level của đơn vị hành chính(level 1 - n). Nhưng vẫn có những nhược điểm như:

- Request 1 điểm mà kết quả dữ liệu trả về 1 mảng,

- Mỗi kết quả trong mảng lại có các level về đơn vị hành chính không đồng nhất(có kết quả có phường-quận- thành phố, nhưng cũng có những kết quả chỉ có quận- thành phố...)

- Không có loại đơn vị hành chính mà chỉ có level

- Giới hạn request free trial rất thấp cho khu vực Việt Nam(3-4 request/day)

Pricing

Pricing của mỗi bên, khảo sát qua tí để đưa ra mức giá phù hợp :))

    Google geocoding pricing

Mapbox geocoding pricing

Brainstorming

    Từ các spec chính đã nêu ở trên, cùng đi chi tiết hơn một chút. Nhìn từ góc độ khách hàng và hệ thống  để xem mỗi bên sẽ ứng xử như thế nào để yêu cầu và đáp ứng được dịch vụ.

• Khách hàng tiếp cận dịch vụ như thế nào?
• Làm sao để dùng thử được dịch vụ trước khi quyết định mua hàng?
• Làm sao để giới hạn số lượng request của khách.
• Làm sao để khách hàng trên toàn thế giới có thể thanh toán tiền cho hệ thống?
• Trang portal của khách sẽ có những tính năng gì?

User flows:

• User sử dụng thử chức năng geo location to administrative location trên trang example
• User đăng ký tài khoản và verify account.
• User xem hướng dẫn sử dụng dịch vụ
• User tạo api key
• User tích hợp API vào hệ thống
• User nhận được mail báo lượng request usage và thanh toán cho hệ thống

System flow:

• Hệ thống đếm và lưu lại số lần request của khách hàng
• Hệ thống verify request của khách hàng
• Hệ thống xử lý request và trả về kết quả
• Hệ thống tính lượng request của khách để đưa ra bill thanh toán theo chu kỳ
• Hệ thống gửi mail thanh toán đến email của khách hàng
• Hệ thống theo dõi tình trạng hóa đơn của khách hàng để đưa ra quyết định

    Phần feature sẽ có thể rất rộng, ở đây mình chỉ hình dung các flow chính để thiết kế hệ thống cho phù hợp.

System architect

    Vậy là đã tạm đủ dữ liệu để hình dung ra bước tranh tổng thể của dự án này rồi. Giờ là lúc lên kiến trúc cho dự án

Logical

Microservices responsibility

• Admin site:  Trang quản trị hệ thống
• Client site: Trang portal chính mà khách hàng sẽ tương tác
• Backend gateway: Gateway cho hệ thống backend phía sau
• User authentication: Service xác thực định danh của khách hàng 
• Billing service: Service thực hiện việc thanh toán, các nghiệp vụ liên quan đến charge tiền khách hàng,
• CRM service: Quản lý khách hàng, Subscription, Controller chính của hệ thống backend
• Report service: Chứa log, phân tích số liệu request của hệ khách hàng
• Geo service: Core service thực hiện các functional liên quan đến geo-location
• Integration API gateway: Gateway cho Geo-service, vì đặc trưng của hệ thống là API as a service nên phải có gateway riêng cho các API dịch vụ expose ra cho khách hàng sử dụng
• API key authentication: Service riêng authenticate các API dịch vụ và trigger request event để limit số lượng request của khách hàng
• Message queue: Hệ thống microservice không thể thiếu được thành phần này, đóng vai trò là kênh giao tiếp bất đồng bộ và xử lý các nghiệp vụ bắt buộc dùng queue
• Notification: Các chức năng liên quan đến gửi thông báo, email...

    Một product đưa ra kinh doanh còn phải kể đến các trang static content như branding site, documentation site, nhưng vì không giao tiếp trực tiếp với các thành phần còn lại nên mình sẽ không đề cập.

Tech stack

    Architect bao gồm các thành phần Frontend, Backend, Message Queue, API Gateway, Database. Các bạn có thể lựa chọn stack phù hợp với bản thân:

• Backend Services: Java Spring
• Frontend: Angular
• Message queue: Kafka
• API gateway: Spring gateway
• Database: Mysql

    Database nên triển khai theo mô hình Database per service, lúc đầu có thể thấy phiền phức vì nhiều DB phải maintain, nhưng sẽ không gặp phải tình trạng bottle neck nếu một service nào đó sử dụng nhiều tài nguyên database, chưa kể đến khả năng phát triển độc lập các service, security.

Kết

   Project này thể hiện được một phần các thành phần của kiến trúc micorservice, với project khác có thể triển khai kết hợp với nhiều stack, concept hơn nữa. Các service  cũng có thể được tách nhỏ hơn nữa tùy điều kiện.

    Bài viết sau mình sẽ triển khai break chi tiết một vài requirement để làm story và đưa vào triển khai trên phạm vi team.

Powered by Sunteco Cloud

    

API as a service P1 - Project requirement and system architect

API as a service P2 - Break story and development strategy

API as a service P3 - Setup environment and develop flow

API as a service P4 - Coding

API as a service P5 - Các vấn đề thường gặp khi triển khai microservice

API as a service P6 - Release production

Transform monolith to microservices in action

1. Why microservices ? 

Microservice là kiến trúc hệ thống phần mềm hướng dịch vụ, chia nhỏ hệ thống ra thành các dịch vụ nhỏ , isolate về  business và dữ liệu. Microservices đã trở nên phổ biến trong những năm trở lại đây, với những ưu điểm nổi bật, nó đang thay thế các ứng dụng monolith. Một số đặc trưng của microservice như sau.

- Triển khai độc lập

Nhờ chia nhỏ 1 ứng dụng lớn ra làm nhiều ứng dụng nhỏ hơn, hệ thống trở lên linh hoạt trong triển khai. Linh hoạt từ việc lựa chọn công nghệ cho đến phân phối tài nguyên. Hệ thống có thể đạt được tiêu chí  scalability, high availability

- Giảm sự phụ thuộc

Các module được xác định rõ trách nhiệm, Việc ràng buộc trong sử dụng chung code business, model và database được giảm xuống.

- Định hướng xoay quanh nghiệp vụ

Microservices hướng đến các dịch vụ xoay quanh business, một service là một ứng dụng có thể chạy độc lập. Development teams thường sẽ chỉ phải tập trung vào phát triển business

- Khả năng phát triển, bảo trì và kiểm thử

Các stack khác nhau có thể được áp dụng chung trong giải pháp tổng thể, thậm chí tái sử dụng từ một hệ thống khác mà không phải lo về sự tương thích. Việc kiểm thử cũng dễ triển khai hơn với các dịch vụ nhỏ, các nghiệp vụ rõ ràng.

Trong bài viết này mình sẽ không đi sâu để so sánh giữa monolith và microservices, xem thêm tại => Monolith and microservice considering.

2. The Microservices Layer ?

    Nếu chúng ta đã quen làm việc với monolith, từ việc code tất cả  trên cùng một repo, một máy chủ dedicated về cấu hình, một database phục vụ tất cả các mục đích... thì việc chuyển đổi qua microservice thực sự là một thử thách. Ở vị trí của người thiết kế hệ thống, có quá nhiều thứ mới để hiểu và áp dụng để có thể có được best P/P (price/ performance) mà vẫn có khả năng mở rộng.

Một kiến trúc microservice hiệu quả là sự phối hợp một các hợp lý giữa các tech stack

Ta có thể chia Microservice làm 4 layer:

2.1 Infastructure layer

    Sự chuyển dịch từ traditional computing sang distributed computing/ cloud computing tạo điều kiện rất thuận lợi cho việc áp dụng kiến trúc microservice. Việc triển khai microservice mà không có sự hỗ trợ từ hạ tầng sẽ tốn nhiều công sức hơn đáng kể. Ở dưới cùng là hạ tầng với các thành phần cơ bản:

- Servers

- Host level loging/ monitoring

- Operating systems

- Resource isolation

- Configuration management

2.2 Communication layer

    Layer này dễ gây nhầm lẫn, bởi vì nó chạm đến tất cả các layer khác trong hệ sinh thái. Nó bao gồm tất cả mọi thứ liên quan đến  giao tiếp giữa ứng dụng, hệ thống và  dịch vụ bao gồm:

- DNS

- Endpoint

- Load balancing

- Messaging

- Network

- Service registry

- Service discovery

2.3 The Application platform

    Layer thứ 3 là nơi chứa tất cả các công cụ nội bộ, hệ thống, dịch vụ mà các microservice chạy trên đó. Một application platform tốt là nơi các công cụ được centralize về mặt quản lý, system-wide về mặt phạm vi. Development teams chỉ cần quan tâm đến các microservice mà họ làm việc, không phải những thứ stuff phía dưới. Layer này bao gồm

- Deployment management(tools and pipeline)

- Development environment

- Application-level logging and monitoring

- Test, package, build and release tools

2.4 The Microservices Layer

Các developer forcus tại layer này và tập trung vào business. Layer này nên độc lập với các layer phía dưới. Nó chỉ chứa các microservices và các cấu hình giữa chúng.

- Microservice

- Microservice configuration

3. Transform the Monolith to Microservice in action

    Cùng xem xét một ứng dụng monolith truyền thống với các tier Presentation, Business logic và Data access layer.

3.1 Business and Tech Stacks:

Các đặc trưng của hệ thống hiện tại

Business: Ứng dụng thương mại điện tử.

Architect: 3 Tiers Application  bao gồm Presentation, Business logic, Data access layer sử dụng Spring MVC, Spring Data

Database: Database sử dụng Mysql

Hosting: Ứng dụng được triển khai bằng file jar và database  trên server đặt tại công ty

3.2 Các issue hệ thống đang gặp phải

- Spring MVC dựa trên kiến trúc server side rendering, multiple pages application, dẫn đến việc load trang lâu hơn

- Hệ thống downtime mỗi khi nâng cấp phiên bản mới, cho dù là tính năng nhỏ nhất của một module

- Hiện tượng bottle neck xuất hiện mỗi khi có nhiều người cùng truy cập hoặc thực hiện các tác vụ nặng, lost các đơn hàng, hệ thống order không hoạt động ổn định, thậm chí down cả dịch vụ. Tăng cấu hình tài nguyên thì tốn kém khi hệ thống tải thấp, nhưng vẫn ko đủ phục vụ khi hệ thống tải cao.

- Chức năng tìm kiếm sản phẩm chậm do dùng query truyền thống

- Quản lý build number của app và data một cách thủ công, bằng cách backup các file vật lý(.jar, sql)

- Hệ thống trace log cũng thủ công bằng cách write ra file, khó để trace lại khi có error

- Hệ thống chứa nhiều module nghiệp vụ, code đang phức tạp và khó maintain, việc phát triển tính năng mới đòi hỏi phải test lại toàn bộ hệ thống

- Ảnh sản phẩm được lưu trữ trực tiếp trên một máy chủ khác, khó quản lý

3.3 Chuyển đổi hệ thống sang microservice

- Chuyển đổi các business module sang microservice: 

    + Authentication, 

    + Product management , 

    + Warehouse,  

    + Order/Payment, 

    + Shipping, 

    + Report,  

    + Client site

    + Cms site

- Chuyển đổi về architect :

    Như phân tích ở trên, vấn đề khó khắc phục nhất trong các issue là vấn đề ứng dụng chạy trên nền tảng dedicated resource ( VM ) dẫn đến không thể kịp thời scale theo lượng tài nguyên yêu cầu, ảnh hưởng trực tiếp đến chất lượng hệ thống và trải nghiệm người dùng. Xem xét các chuyển đổi về architect:

    + Triển khai ứng dụng dựa trên container orchestration (K8S concept) , phục vụ mục đích scalability, high availability

    + Tối ưu tìm kiếm sản phẩm bằng việc dựng thêm elastic service, đồng bộ với Product database

    + Xem xét nâng cấp database sang mô hình master-slave để tối ưu hiệu quả đọc ghi.

    + Load balancer cân bằng tải cho các instance mỗi khi hệ thống cao tải

    + API gateway giúp ẩn kiến trúc phía sau và authentication/ request logging tập trung

    + Lựa chọn công nghệ message queue cho giao tiếp bất đồng bộ giữa microservices

    + Client site và cms site sử dụng công nghệ client site rendering (angular/react) để đạt higher             performance. Việc phát triển tầng UI và business logic được tách biệt 

    + Separate các database cho mỗi dịch vụ, tăng resource cho các database có nhiều request, thậm chí áp dụng DB replica, master/slave   => tăng tính bảo mật và upgrade về sau

    + Sử dụng docker hub hoặc private image registry để lưu trữ các bản build của service dưới dạng image tag.

    + Áp dụng các công nghệ có thể backup data dưới dạng backup volume bên cạnh dạng backup file truyền thống

    + Chọn một stack cho việc lưu trữ file (ảnh sản phẩm, Database backup ) : Object storage  technology(Sun S3)

3.3 Lựa chọn tech stack, provider và triển khai

    Với cùng một thiết kế hệ thống, chúng ta có thể điều chỉnh lựa chọn tech stack và provider phù hợp với hoàn cảnh của mỗi công ty. Trên thị trường quốc tế có các tên tuổi lớn về cloud provider và app platform nổi tiếng như AWS, GCP, Microsoft azure. Trong nước thì có các nhà cung cấp như VNG cloud, Viettel IDC, CMC, FPT, Sunteco cloud với các mức giá và dịch vụ khác nhau. Mình sẽ triển khai hệ thống này trên Sunteco cloud, lấy trọng tâm là Sun Spinner, đây là dịch vụ dựa trên concept của K8S, hỗ trợ sẵn Load balancing, HA và scability chỉ với vài click. Một Sun-spinner có thể chứa một hoặc nhiều container.

- Sau khi build các service sang dạng image và đẩy lên docker hub, setup các Sun Spinner cluster từ giao diện

- Sun Spinner cho phép run bất kì image nào trên docker hub hoặc các image registry khác, thao tác hoàn toàn qua UI

- Database có thể được triển khai qua 3 cách trên Sunteco cloud, 

    + Tạo một mysql-spinner sau đó sử dụng persistance volume(Vùng nhớ lưu trữ lâu dài)  và mount vào data stored path của mysql-spinner 

    + Cách truyền thống hơn là sử dụng dịch vụ Sun VM để host database với dedicated resource 

    + Dịch vụ Database as a service (Comming soon)

- Các service-config được setup qua hệ thống Secret/ Configmap và mount trực tiếp vào Spinner . Đơn giản hóa quá trình quản lý configuration

- Các trang static web(landing page) có thể host trên Sun VM hoặc Sun S3 storage

- Message queue sử dụng Sun Highway (kafka as a service)

    Vòng đời của các service: CICD => push to docker hub => Sun spinner pull image =>Service booting =>  Service running. Có một góp ý nhỏ là Spinner chưa có cơ chế tích hợp với hệ thống CICD của các doanh nghiệp, có lẽ cần một api callback để trigger việc cập nhật ứng dụng lên phiên bản mới. Hiện tại phải lên portal của Sunteco Cloud để manual update version mới hoặc setup Sun Spimner với auto update policy. Nhờ việc chỉ cần facing ứng dụng web và api gateway ra ngoài, các ứng dụng phía sau giao tiếp với nhau qua internal endpoint, message broker mà performance và security được nâng cao. Mình chưa đề cập đến vấn đề database relication, xin hẹn ở những bài viết sau.

4. Conclusion

     Bạn có thể cân nhắc chuyển đổi toàn bộ hoặc từng phần ứng dụng của doanh nghiệp với mức chi phí nhỏ nhất để đặt được hiệu quả tốt nhất. Công nghệ container cho phép ứng dụng có thể scale một các tùy ý. Spinner của Sunteco có pricing theo giờ, có nghĩa là nếu hệ thống tải bình thường thì lượng tiêu thụ chỉ tương đương với VM cùng cấu hình, nhưng khi hệ thống tăng tải, cấu hình được tự động scale ngay lập tức để đáp ứng nhu cầu, khi hệ thống giảm tải, cấu hình lại trở về mức bình thường. Tất cả các nhu cầu này nếu tự dựng một hệ thống K8S rồi tự setup sẽ tốn khá nhiều nguồn lực và chưa chắc đã hoạt động ổn định.Việc chuyển đổi từ kiến trúc monolith sang microservice hoặc xây dựng mới hoàn toàn là không dễ dàng, nhưng nó rất đáng giá để thực hiện.

Reference

https://www.susanjfowler.com/blog/2016/12/18/the-four-layers-of-microservice-architecture