Vien Truong

Trong SOA, services thường trở thành các cục monolithic với nhiều hàm, chức năng khác hỗ trợ.

<h2>Kiến trúc nguyên khối (Monolithic Architecture)</h2>

Ứng dụng phần mềm doanh nghiệp được thiết kế để đáp ứng nhiều yêu cầu kinh doanh của doanh nghiệp. Do đó, các phần mềm cung cấp hàng trăm các tính năng và tất cả những tính năng này đều được gói trong một ứng dụng monolithic. Ví dụ: ERPs, CRMs hay nhiều phần mềm khác chứa hàng trăm tính năng. Việc triển khai, sửa lỗi, mở rộng và nâng cấp những phần mềm khổng lồ này trở thành một cơn ác mộng.

Kiến trúc hướng dịch vụ (Service Oriented Architecture – SOA) được thiết kể để giải quyết một phần của vấn đề bằng cách giới thiệu khái niệm “service”. Một dịch vụ (service) là một nhóm tổng hợp các tính năng tương tự trong một ứng dụng. Do đó trong SOA, ứng dụng phần mềm được thiết kế như một tổ hợp của các dịch vụ. Tuy nhiên, với SOA, giới hạn hay phạm vi của một dịch vụ khá là rộng và được định nghĩa khá “thô” (coarse-grained). Việc này khiến các services cũng có thể trở nên quá to và phức tạp.

 

<img alt="" height="282" src="/ckfinder/userfiles/images/image-20220905135954-3.png" width="241" />

Trong phần lớn trường hợp, dịch vụ trong SOA là độc lập nhưng chúng lại được triển khai chung. Tương tự như ứng dụng monolithic, những dịch vụ này to và phức tạp lên theo thời gian vì thường xuyên thêm các tính năng. Và thế là những ứng dụng này lại trở thành một mớ các dịch vụ monolithic, cũng không còn khác mấy so với kiến trúc nguyên khối thông thường.

Hình 1 thể hiện một ứng dụng gồm nhiều services. Những services này được triển khai cùng một lúc vào 1 ứng dụng lớn. Dù bên trong có gồm các services thì đây là một ứng dụng monolithic. Một số tính chất của kiến trúc nguyên khối (Monolithic Architecture):

<ul>
	<li>Được thiết kế, phát triển và triển khai theo một khối duy nhất.</li>
	<li>Ứng dụng monolithic phức tạp và to gây khó khăn cho việc bảo trì, nâng cấp và thêm tính năng mới.</li>
	<li>Khó áp dụng phát triển kiểu Agile.</li>
	<li>Phải triển khai lại toàn bộ hệ thống dù chỉ cập nhật hay nâng cấp một phần.</li>
	<li>Mở rộng: phải mở rộng cả khối ứng dụng, gặp khó khăn nếu có các yêu cầu về tài nguyên khác nhau (ví dụ một service yêu cầu thêm CPU, service khác lại yêu cầu nhiều memory).</li>
	<li>Độ tin cậy: một service không ổn định có thể sập cả hệ thống.</li>
	<li>Khó đổi mới: ứng dụng monolithic phải sử dụng chung công nghệ nên khó thay đổi hay áp dụng công nghệ mới.</li>
</ul>

Những tính chất giới hạn trên của kiến trúc nguyên khối dẫn tới sự phát triển của kiến trúc dịch vụ nhỏ (Microservices Architecture).

<h2>Kiến trúc dịch vụ nhỏ (Microservices Architecture)</h2>

Mục tiêu nền tảng của kiến trúc microservices là xây dựng một ứng dụng mà ứng dụng này là tổng hợp của nhiều services nhỏ và độc lập có thể chạy riêng biệt, phát triển và triển khai độc lập.

Một số khái niệm về microservices nói về quá trình chia tách ứng dụng monolithic thành nhóm các services độc lập. Tuy nhiên, theo quan điểm của tôi, microservices không chỉ về chia tách các servcies sẵn có trong monolithic.

Ý tưởng quan trọng chính là nhìn vào các tính năng trong một ứng dụng monolithic, ta có thể nhận biết, xác định các yêu cầu và khả năng cần thiết để đáp ứng một nghiệp vụ. Sau đó từng năng lực nghiệp vụ này sẽ được xây dựng thành những service nhỏ, độc lập. Những services này có thể sử dụng các nền tảng công nghệ khác nhau và phục vụ một mục đích cụ thể và có giới hạn.

Theo đó, ví dụ về hệ thống trong hình 1 có thể được chia theo microservices như trong hình 2. Đây có thể là một ứng dụng phần mềm bán hàng, với kiến trúc microservices, mỗi chức năng kinh doanh hay trong doanh nghiệp được tách thành một microservices. Trong kiến trúc microservices, một service mới được tạo ra từ những services gốc trong kiến trúc monolithic.

 

<img alt="" height="322" src="/ckfinder/userfiles/images/image-20220905140008-4.png" width="302" />

Tiếp theo, chúng ta sẽ nói về các nguyên tắc chính của kiến trúc microservices và quan trọng hơn chính là cách chúng được sử dụng trong thực tế.

<h2>Thiết kế Microservices: kích cỡ, phạm vi và tính năng</h2>

Bạn có thể xây dựng ứng dụng mới với microservices hoặc chuyển đổi ứng dụng sẵn có sang microservices. Với cách nào thì việc quyết định kích cỡ, phạm vi và tính năng của microservices rất quan trọng. Có thể đây chính là phần khó nhất bạn gặp phải khi phát triển hệ thống microservices trong thực tế.

Dưới đây chúng ta sẽ xem xét một số vấn đề thực tế và những hiểu sai về kích cỡ, phạm vi và chức năng của microservices.

<ul>
	<li>Số dòng code/ kích cỡ của một đội lập trình là chỉ số không chính xác: có vài cuộc bàn luận về kích thước của một service dựa vào số lượng dòng code hay kích thước của đội phát triển service đó (ví dụ <a href="http://blog.idonethis.com/two-pizza-team/">two-pizza team</a>). Tuy nhiên, những cách đo đếm này không thực tiễn và không chính xác, vì ta có thể phát triển services với ít dòng code hoặc với một đội nhỏ nhưng hoàn toàn đảm bảo được các nguyên lý trong kiến trúc microservices.</li>
	<li>“Micro” là một từ khóa dễ gây nhầm lẫn. Một số lập trình viên nghĩ rằng họ nên tạo ra services nhỏ hết mức. Điều này là một cách hiểu sai.</li>
	<li>Trong SOA, services thường trở thành các cục monolithic với nhiều hàm, chức năng khác hỗ trợ. Vì vậy, chỉ phát triển services kiểu SOA rồi dán nhãn microservices hoàn toàn lạc hướng và không mang lại bất kì lợi ích nào của kiến trúc microservices.</li>
</ul>

Do đó, câu hỏi là chúng ta nên thiết kế services trong kiến trúc microservices như thế nào thì phù hợp và đúng mực?

Hiện nay, “Microservices” là một trong những thuật ngữ hay từ khóa phổ biến nhất (buzz-words) trong lĩnh vực kiến trúc phần mềm. Bạn có thể tìm thấy khá nhiều tài liệu giới thiệu và nói về những nguyên tắt cũng như lợi ích của microservices, tuy nhiên khá ít tài liệu hướng dẫn cách áp dụng microservices trong những hoàn cảnh thực tế. Bài này chúng ta sẽ tìm hiểu về các khái niệm chính về kiến trúc microservices (MSA) và cách mà bạn sử dụng những nguyên lý này trong thực tiễn.

<h2>Kiến tr&uacute;c nguy&ecirc;n khối (Monolithic Architecture)</h2>

Ứng dụng phần mềm doanh nghiệp được thiết kế để đ&aacute;p ứng nhiều y&ecirc;u cầu kinh doanh của doanh nghiệp. Do đ&oacute;, c&aacute;c phần mềm cung cấp h&agrave;ng trăm c&aacute;c t&iacute;nh năng v&agrave; tất cả những t&iacute;nh năng n&agrave;y đều được g&oacute;i trong một ứng dụng monolithic. V&iacute; dụ: ERPs, CRMs hay nhiều phần mềm kh&aacute;c chứa h&agrave;ng trăm t&iacute;nh năng. Việc triển khai, sửa lỗi, mở rộng v&agrave; n&acirc;ng cấp những phần mềm khổng lồ n&agrave;y trở th&agrave;nh một cơn &aacute;c mộng.

Kiến tr&uacute;c hướng dịch vụ (Service Oriented Architecture &ndash;&nbsp;SOA) được thiết kể để giải quyết một phần của vấn đề bằng c&aacute;ch giới thiệu kh&aacute;i niệm &ldquo;service&rdquo;. Một dịch vụ (service) l&agrave; một nh&oacute;m tổng hợp c&aacute;c t&iacute;nh năng tương tự trong một ứng dụng. Do đ&oacute; trong&nbsp;SOA, ứng dụng phần mềm được thiết kế như một tổ hợp của c&aacute;c dịch vụ. Tuy nhi&ecirc;n, với SOA, giới hạn hay phạm vi của một dịch vụ kh&aacute; l&agrave; rộng v&agrave; được định nghĩa kh&aacute; &ldquo;th&ocirc;&rdquo; (coarse-grained). Việc n&agrave;y khiến c&aacute;c services cũng c&oacute; thể trở n&ecirc;n qu&aacute; to v&agrave; phức tạp.

&nbsp;

<img alt="" height="282" src="/ckfinder/userfiles/images/image-20220905135954-3.png" width="241" />

Trong phần lớn trường hợp, dịch vụ trong SOA l&agrave; độc lập nhưng ch&uacute;ng lại được triển khai chung. Tương tự như ứng dụng monolithic, những dịch vụ n&agrave;y to v&agrave; phức tạp l&ecirc;n theo thời gian v&igrave; thường xuy&ecirc;n th&ecirc;m c&aacute;c t&iacute;nh năng. V&agrave; thế l&agrave; những ứng dụng n&agrave;y lại trở th&agrave;nh một mớ c&aacute;c dịch vụ monolithic, cũng kh&ocirc;ng c&ograve;n kh&aacute;c mấy so với kiến tr&uacute;c nguy&ecirc;n khối th&ocirc;ng thường.

H&igrave;nh 1&nbsp;thể hiện một ứng dụng gồm nhiều services. Những services n&agrave;y được triển khai c&ugrave;ng một l&uacute;c v&agrave;o 1 ứng dụng lớn. D&ugrave; b&ecirc;n trong c&oacute; gồm c&aacute;c services th&igrave; đ&acirc;y l&agrave; một ứng dụng monolithic. Một số t&iacute;nh chất của kiến tr&uacute;c nguy&ecirc;n khối (Monolithic Architecture):

<ul>
	<li>Được thiết kế, ph&aacute;t triển v&agrave; triển khai theo một khối duy nhất.</li>
	<li>Ứng dụng monolithic phức tạp v&agrave; to g&acirc;y kh&oacute; khăn cho việc bảo tr&igrave;, n&acirc;ng cấp v&agrave; th&ecirc;m t&iacute;nh năng mới.</li>
	<li>Kh&oacute; &aacute;p dụng ph&aacute;t triển kiểu Agile.</li>
	<li>Phải triển khai lại to&agrave;n bộ hệ thống d&ugrave; chỉ cập nhật hay n&acirc;ng cấp một phần.</li>
	<li>Mở rộng: phải mở rộng cả khối ứng dụng, gặp kh&oacute; khăn nếu c&oacute; c&aacute;c y&ecirc;u cầu về t&agrave;i nguy&ecirc;n kh&aacute;c nhau (v&iacute; dụ một service y&ecirc;u cầu th&ecirc;m CPU, service kh&aacute;c lại y&ecirc;u cầu nhiều memory).</li>
	<li>Độ tin cậy: một service kh&ocirc;ng ổn định c&oacute; thể sập cả hệ thống.</li>
	<li>Kh&oacute; đổi mới: ứng dụng monolithic phải sử dụng chung c&ocirc;ng nghệ n&ecirc;n kh&oacute; thay đổi hay &aacute;p dụng c&ocirc;ng nghệ mới.</li>
</ul>

Những t&iacute;nh chất giới hạn tr&ecirc;n của kiến tr&uacute;c nguy&ecirc;n khối dẫn tới sự ph&aacute;t triển của kiến tr&uacute;c dịch vụ nhỏ (Microservices Architecture).

<h2>Kiến tr&uacute;c dịch vụ nhỏ (Microservices Architecture)</h2>

Mục ti&ecirc;u nền tảng của kiến tr&uacute;c microservices l&agrave; x&acirc;y dựng một ứng dụng m&agrave; ứng dụng n&agrave;y l&agrave; tổng hợp của nhiều services nhỏ v&agrave;&nbsp;độc lập c&oacute; thể chạy ri&ecirc;ng biệt, ph&aacute;t triển v&agrave; triển khai độc lập.

Một số kh&aacute;i niệm về microservices n&oacute;i về qu&aacute; tr&igrave;nh chia t&aacute;ch ứng dụng monolithic th&agrave;nh nh&oacute;m c&aacute;c services độc lập. Tuy nhi&ecirc;n, theo quan điểm của t&ocirc;i, microservices kh&ocirc;ng chỉ về chia t&aacute;ch c&aacute;c servcies sẵn c&oacute; trong monolithic.

&Yacute; tưởng quan trọng ch&iacute;nh l&agrave; nh&igrave;n v&agrave;o c&aacute;c t&iacute;nh năng trong một ứng dụng monolithic, ta c&oacute; thể nhận biết, x&aacute;c định c&aacute;c y&ecirc;u cầu v&agrave; khả năng cần thiết để đ&aacute;p ứng một nghiệp vụ. Sau đ&oacute; từng năng lực nghiệp vụ n&agrave;y sẽ được x&acirc;y dựng th&agrave;nh những service nhỏ, độc lập.&nbsp;Những services n&agrave;y c&oacute; thể sử dụng c&aacute;c nền tảng c&ocirc;ng nghệ kh&aacute;c nhau v&agrave; phục vụ một mục đ&iacute;ch cụ thể v&agrave; c&oacute; giới hạn.

Theo đ&oacute;, v&iacute; dụ về hệ thống trong&nbsp;h&igrave;nh 1&nbsp;c&oacute; thể được chia theo microservices như trong&nbsp;h&igrave;nh 2. Đ&acirc;y c&oacute; thể l&agrave; một ứng dụng phần mềm b&aacute;n h&agrave;ng, với kiến tr&uacute;c microservices, mỗi chức năng kinh doanh hay trong doanh nghiệp được t&aacute;ch th&agrave;nh một microservices. Trong kiến tr&uacute;c microservices, một service mới được tạo ra từ những services gốc trong kiến tr&uacute;c monolithic.

&nbsp;

<img alt="" height="322" src="/ckfinder/userfiles/images/image-20220905140008-4.png" width="302" />

Tiếp theo, ch&uacute;ng ta sẽ n&oacute;i về c&aacute;c nguy&ecirc;n tắc ch&iacute;nh của kiến tr&uacute;c microservices v&agrave; quan trọng hơn ch&iacute;nh l&agrave; c&aacute;ch ch&uacute;ng được sử dụng trong thực tế.

<h2>Thiết kế Microservices: k&iacute;ch cỡ, phạm vi v&agrave; t&iacute;nh năng</h2>

Bạn c&oacute; thể x&acirc;y dựng ứng dụng mới với microservices hoặc chuyển đổi ứng dụng sẵn c&oacute; sang microservices. Với c&aacute;ch n&agrave;o th&igrave; việc quyết định k&iacute;ch cỡ, phạm vi v&agrave; t&iacute;nh năng của microservices rất quan trọng. C&oacute; thể đ&acirc;y ch&iacute;nh l&agrave; phần kh&oacute; nhất bạn gặp phải khi ph&aacute;t triển hệ thống microservices trong thực tế.

Dưới đ&acirc;y ch&uacute;ng ta sẽ xem x&eacute;t một số vấn đề thực tế v&agrave; những hiểu sai về k&iacute;ch cỡ, phạm vi v&agrave; chức năng của microservices.

<ul>
	<li>Số d&ograve;ng code/ k&iacute;ch cỡ của một đội lập tr&igrave;nh l&agrave; chỉ số kh&ocirc;ng ch&iacute;nh x&aacute;c: c&oacute; v&agrave;i cuộc b&agrave;n luận về k&iacute;ch thước của một service dựa v&agrave;o số lượng d&ograve;ng code hay k&iacute;ch thước của đội ph&aacute;t triển service đ&oacute; (v&iacute; dụ&nbsp;<a href="http://blog.idonethis.com/two-pizza-team/">two-pizza team</a>). Tuy nhi&ecirc;n, những c&aacute;ch đo đếm n&agrave;y kh&ocirc;ng thực tiễn v&agrave; kh&ocirc;ng ch&iacute;nh x&aacute;c, v&igrave; ta c&oacute; thể ph&aacute;t triển services với &iacute;t d&ograve;ng code hoặc với một đội nhỏ nhưng ho&agrave;n to&agrave;n đảm bảo được c&aacute;c nguy&ecirc;n l&yacute; trong kiến tr&uacute;c microservices.</li>
	<li>&ldquo;Micro&rdquo; l&agrave; một từ kh&oacute;a dễ g&acirc;y nhầm lẫn. Một số lập tr&igrave;nh vi&ecirc;n nghĩ rằng họ n&ecirc;n tạo ra services nhỏ hết mức. Điều n&agrave;y l&agrave; một c&aacute;ch hiểu sai.</li>
	<li>Trong SOA, services thường trở th&agrave;nh c&aacute;c cục monolithic với nhiều h&agrave;m, chức năng kh&aacute;c hỗ trợ. V&igrave; vậy, chỉ ph&aacute;t triển services kiểu SOA rồi d&aacute;n nh&atilde;n microservices ho&agrave;n to&agrave;n lạc hướng v&agrave; kh&ocirc;ng mang lại bất k&igrave; lợi &iacute;ch n&agrave;o của kiến tr&uacute;c microservices.</li>
</ul>

Do đ&oacute;, c&acirc;u hỏi l&agrave; ch&uacute;ng ta n&ecirc;n thiết kế services trong kiến tr&uacute;c microservices như thế n&agrave;o th&igrave; ph&ugrave; hợp v&agrave; đ&uacute;ng mực?

Microservices: Cưỡi ngựa xem hoa - Phần 1

<h2>Thiết kế Microservices: k&iacute;ch cỡ, phạm vi v&agrave; t&iacute;nh năng</h2>

&nbsp;

Dưới đ&acirc;y ch&uacute;ng ta sẽ xem x&eacute;t một số vấn đề thực tế v&agrave; những hiểu sai về k&iacute;ch cỡ, phạm vi v&agrave; chức năng của microservices.

<ul>
	<li>Số d&ograve;ng code/ k&iacute;ch cỡ của một đội lập tr&igrave;nh l&agrave; chỉ số kh&ocirc;ng ch&iacute;nh x&aacute;c: c&oacute; v&agrave;i cuộc b&agrave;n luận về k&iacute;ch thước của một service dựa v&agrave;o số lượng d&ograve;ng code hay k&iacute;ch thước của đội ph&aacute;t triển service đ&oacute; (v&iacute; dụ&nbsp;<a href="http://blog.idonethis.com/two-pizza-team/">two-pizza team</a>). Tuy nhi&ecirc;n, những c&aacute;ch đo đếm n&agrave;y kh&ocirc;ng thực tiễn v&agrave; kh&ocirc;ng ch&iacute;nh x&aacute;c, v&igrave; ta c&oacute; thể ph&aacute;t triển services với &iacute;t d&ograve;ng code hoặc với một đội nhỏ nhưng ho&agrave;n to&agrave;n đảm bảo được c&aacute;c nguy&ecirc;n l&yacute; trong kiến tr&uacute;c microservices.</li>
	<li>&ldquo;Micro&rdquo; l&agrave; một từ kh&oacute;a dễ g&acirc;y nhầm lẫn. Một số lập tr&igrave;nh vi&ecirc;n nghĩ rằng họ n&ecirc;n tạo ra services nhỏ hết mức. Điều n&agrave;y l&agrave; một c&aacute;ch hiểu sai.</li>
	<li>Trong SOA, services thường trở th&agrave;nh c&aacute;c cục monolithic với nhiều h&agrave;m, chức năng kh&aacute;c hỗ trợ. V&igrave; vậy, chỉ ph&aacute;t triển services kiểu SOA rồi d&aacute;n nh&atilde;n microservices ho&agrave;n to&agrave;n lạc hướng v&agrave; kh&ocirc;ng mang lại bất k&igrave; lợi &iacute;ch n&agrave;o của kiến tr&uacute;c microservices.</li>
</ul>

Do đ&oacute;, c&acirc;u hỏi l&agrave; ch&uacute;ng ta n&ecirc;n thiết kế services trong kiến tr&uacute;c microservices như thế n&agrave;o th&igrave; ph&ugrave; hợp v&agrave; đ&uacute;ng mực?

<h2>Một Số Chỉ Dẫn Khi Thiết Kế Microservices</h2>

<ul>
	<li>Single Responsibility Principle (SRP): một service với phạm vi v&agrave; chức năng giới hạn, tập trung v&agrave;o một nhiệm vụ gi&uacute;p qu&aacute; tr&igrave;nh ph&aacute;t triển v&agrave; triển khai dịch vụ trở n&ecirc;n nhanh ch&oacute;ng hơn.</li>
	<li>Trong qu&aacute; tr&igrave;nh thiết kế, ta n&ecirc;n x&aacute;c định v&agrave; giới hạn c&aacute;c services theo chức năng nghiệp vụ thực tế (theo&nbsp;<a href="http://martinfowler.com/bliki/BoundedContext.html">Domain-Driven-Design</a>).</li>
	<li>Đảm bảo microservices c&oacute; thể ph&aacute;t triển v&agrave; triển khai độc lập.</li>
	<li>Mục ti&ecirc;u của thiết kế l&agrave; phạm vi của microservices phục vụ một nghiệp vụ chứ kh&ocirc;ng chỉ đơn giản l&agrave;m c&aacute;c dịch vụ nhỏ hơn. K&iacute;ch thước hợp l&yacute; của một service l&agrave; k&iacute;ch thước đủ để đ&aacute;p ứng y&ecirc;u cầu của một chức năng trong hệ thống.</li>
	<li>Kh&aacute;c với services trong SOA, một microservice kh&ocirc;ng n&ecirc;n c&oacute; qu&aacute; nhiều h&agrave;m hay chức năng hỗ trợ xung quanh v&agrave; định dạng th&ocirc;ng b&aacute;o/ gửi tin (messaging) phải đơn giản.</li>
	<li>Một c&aacute;ch tốt l&agrave; c&oacute; thể bắt đầu với services to c&oacute; phạm vi rộng rồi chia nhỏ dần (dựa theo nghiệp vụ thực tế của hệ thống).</li>
</ul>

Trong v&iacute; dụ về hệ thống b&aacute;n h&agrave;ng, bạn c&oacute; thể thấy ứng dụng monolithic được t&aacute;ch th&agrave;nh bốn microservices l&agrave; &ldquo;inventory&rdquo;, &ldquo;accounting&rdquo;, &ldquo;shipping&rdquo; v&agrave; &ldquo;store&rdquo;. Ch&uacute;ng giải quyết một y&ecirc;u cầu giới hạn nhất định nhưng tập trung v&agrave;o chức năng đ&oacute;. Theo đ&oacute;, mỗi service t&aacute;ch biệt ho&agrave;n to&agrave;n khỏi nhau v&agrave; đảm bảo t&iacute;nh linh hoạt v&agrave; độc lập.

Ồ, nếu t&aacute;ch c&aacute;c services ra độc lập, vậy l&agrave;m sao li&ecirc;n lạc v&agrave; trao đổi th&ocirc;ng tin/dữ liệu giữa c&aacute;c services với nhau?

<h2>Li&ecirc;n lạc giữa Microservices</h2>

Trong ứng dụng monolithic, c&aacute;c chức năng kh&aacute;c nhau nằm trong c&aacute;c component kh&aacute;c nhau được kết nối bằng c&aacute;ch gọi h&agrave;m hay phương thức. Trong SOA, việc n&agrave;y được chuyển sang một chế độ t&aacute;ch rời hơn với kiểu nhắn tin qua c&aacute;c dịch vụ web (web service messaging), phần lớn d&ugrave;ng SOAP tr&ecirc;n nền giao thức HTTP, JMS. Những webservices n&agrave;y kh&aacute; phức tạp. Như đ&atilde; n&oacute;i ở tr&ecirc;n, microservices y&ecirc;u cầu l&agrave; phải c&oacute; một cơ chế truyền tin đơn giản v&agrave; nhẹ.

Vậy đ&oacute; l&agrave; những cơ chế n&agrave;o?

<h2>&nbsp;</h2>

<h2>Gửi Tin Đồng Bộ &ndash; REST, Thrift</h2>

Với truyền tin đồng bộ (người gửi &ndash; client sẽ chờ một khoảng thời gian để nhận kết quả từ service), REST l&agrave; sự lựa chọn h&agrave;ng đầu v&igrave; n&oacute; cung cấp hệ thống truyền tin đơn giản qua giao thức HTTP dạng request &ndash; response. Do đ&oacute;, nhiều microservices sử dụng HTTP với API. Mỗi chức năng sẽ xuất ra (expose) API.

&nbsp;

Ngo&agrave;i REST, Thrift cũng được sử dụng để truyền tin đồng bộ.

<h3>Gửi Tin Bất Đồng Bộ &ndash; AMQP, STOMP, MQTT</h3>

Trong một số kịch bản, truyền tin bất đồng bộ l&agrave; cần thiết (client kh&ocirc;ng mong đợi response ngay lập tức, hoặc kh&ocirc;ng cần response). C&aacute;c giao thức truyền tin bất đồng bộ như AMQP, STOMP hay MQTT được sử dụng rộng r&atilde;i.

Như vậy l&agrave; ch&uacute;ng ta c&oacute; gửi tin nhắn đồng bộ hoặc bất đồng bộ. Nhưng n&ecirc;n định dạng cho tin nhắn thế n&agrave;o đ&acirc;y?

<h3>C&aacute;c Định Dạng Tin Nhắn &ndash; JSON, XML, Thrift, ProtoBuf, Avro</h3>

Quyết định định dạng tin nhắn ph&ugrave; hợp cho microservices cũng l&agrave; một yếu tố quan trọng. Với phần lớn c&aacute;c ứng dụng microservices, họ sử dụng những kiểu tin nhắn dạng chữ như JSON v&agrave; XML tr&ecirc;n nền giao thức HTTP với API. Trong trường hợp cần truyền tin dạng nhị ph&acirc;n, microservices c&oacute; thể d&ugrave;ng dạng Thrift, Proto hay Avro.

<h3>Service Contracts &ndash; Định Nghĩa Service Interfaces &ndash; Swagger, RAML</h3>

Khi bạn c&oacute; một nghiệp vụ được x&acirc;y dựng như một dịch vụ, bạn cần định nghĩa v&agrave; th&ocirc;ng b&aacute;o hợp đồng dịch vụ (service contract thể hiện giao k&egrave;o của service).

Bởi v&igrave; ch&uacute;ng ta x&acirc;y dựng microservices tr&ecirc;n kiểu kiến tr&uacute;c REST, ta c&oacute; thể sử dụng c&ugrave;ng kiểu REST API để định nghĩa hợp đồng của microservices. Do đ&oacute;, microservices sử dụng c&aacute;c ng&ocirc;n ngữ định nghĩa REST API ti&ecirc;u chuẩn như Swagger, RAML để định nghĩa hợp đồng dịch vụ.

Đối với trường hợp microservices kh&ocirc;ng được triển khai dựa tr&ecirc;n HTTP/REST (cụ thể l&agrave; d&ugrave;ng Thrift), ch&uacute;ng ta c&oacute; thể d&ugrave;ng mức độ giao thức &lsquo;Interface Definition Languages&rsquo; (v&iacute; dụ:&nbsp;<a href="https://thrift.apache.org/docs/idl">Thrift IDL</a>)

<h3>Kết Nối Microservices (Giao Tiếp Giữa C&aacute;c Services)</h3>

Trong kiến tr&uacute;c microservices, ứng dụng phần mềm được cấu th&agrave;nh từ c&aacute;c dịch vụ độc lập. Để ho&agrave;n th&agrave;nh một t&aacute;c vụ của người d&ugrave;ng tr&ecirc;n phần mềm, kết nối v&agrave; giao tiếp giữa c&aacute;c microservices l&agrave; cần thiết v&igrave; t&aacute;c vụ gồm nhiều t&aacute;c động kh&aacute;c nhau l&ecirc;n c&aacute;c services. V&igrave; vậy, giao tiếp giữa c&aacute;c microservices l&agrave; một vấn đề cực k&igrave; quan trọng.

Khi &aacute;p dụng SOA, giao tiếp giữa c&aacute;c services được tiến h&agrave;nh bởi một Enterprise Service Bus (ESB) v&agrave; phần lớn logic nằm trong tầng trung gian n&agrave;y (định tuyến cho tin nhắn, chuyển đổi v&agrave; điều phối tin nhắn). Tuy nhi&ecirc;n, kiến tr&uacute;c microservices th&uacute;c đẩy việc loại trừ một tầng giao tiếp trung gian tập trung/ ESB v&agrave; chuyển phần &lsquo;smart-ness&rsquo; hay business logic sang c&aacute;c services (n&oacute; được gọi l&agrave; &lsquo;Smart Endpoints&rsquo;).

Bởi v&igrave; microservices sử dụng giao thức ti&ecirc;u chuẩn như HTTP/REST, JSON, &hellip;, Cho n&ecirc;n c&aacute;c giao tiếp giữa c&aacute;c microservices được cố gắng thống nhất về giao thức v&agrave; hạn chế tối đa việc t&iacute;ch hợp với một giao thức kh&aacute;c. Một lựa chọn kh&aacute;c cho giao tiếp giữa microservices l&agrave; sử dụng một message bus nhẹ hay gateway với khả năng định tuyến tối thiểu hoạt động như những đường truyền đơn thuần kh&ocirc;ng xử l&yacute; business logic g&igrave; hết (dump pipe). Dựa v&agrave;o những phong c&aacute;ch n&agrave;y, c&oacute; một số kiểu mẫu giao tiếp trong microservices như dưới đ&acirc;y.

<h3>Point-to-point &ndash; Kết Nối Trực Tiếp Giữa C&aacute;c Services</h3>

Với kiểu kết nối trực tiếp điểm nối điểm, to&agrave;n bộ logic của việc định tuyến truyền tin nhắn nằm trong mỗi điểm cuối (endpoint) hay ch&iacute;nh l&agrave; c&aacute;c services. V&agrave; services n&oacute;i chuyện trực tiếp với nhau. Mỗi service mở ra một REST APIs v&agrave; bất k&igrave; service hay kh&aacute;ch h&agrave;ng b&ecirc;n ngo&agrave;i n&agrave;o cũng c&oacute; thể gọi service qua REST API của n&oacute;.

<img alt="" height="399" src="https://uat.admin.careers.saigontechnology.vn/ckfinder/userfiles/images/microservices-logical.png" width="987" />

R&otilde; r&agrave;ng l&agrave; m&ocirc; h&igrave;nh n&agrave;y đơn giản v&agrave; hoạt động ổn với ứng dụng microservices tương đối nhỏ nhưng khi số lượng services tăng l&ecirc;n, việc giao tiếp trở n&ecirc;n cực phức tạp. Đ&acirc;y l&agrave; l&yacute; do trong m&ocirc; h&igrave;nh SOA truyền thống người ta sử dụng Enterprise Service Bus (ESB), ch&iacute;nh l&agrave; để loại bỏ kết nối trực tiếp phức tạp v&agrave; rối rắm. Sau đ&acirc;y l&agrave; một số nhược điểm của kiểu giao tiếp trực tiếp (point to point).

<ul>
	<li>Những y&ecirc;u cầu như x&aacute;c thực người d&ugrave;ng, điều tiết, gi&aacute;m s&aacute;t,&hellip;phải được thực hiện (implement) ở mọi microservices.</li>
	<li>Việc tr&ecirc;n dẫn đến c&aacute;c t&iacute;nh năng phổ biến bị tr&ugrave;ng lặp, việc thực hiện mỗi microservices c&oacute; thể trở n&ecirc;n phức tạp.</li>
	<li>Kh&ocirc;ng c&oacute; c&aacute;ch quản l&yacute;, kiểm so&aacute;t giao tiếp giữa c&aacute;c services (chẳng hạn như muốn theo d&otilde;i, truy t&igrave;m hay lọc c&aacute;c giao h&agrave;nh động giữa c&aacute;c services).</li>
	<li>Thường việc kết nối trực tiếp trong microservices được coi l&agrave;&nbsp;<a href="https://www.infoq.com/articles/seven-uservices-antipatterns">anti-pattern</a>&nbsp;cho việc triển khai c&aacute;c ứng dụng microservice c&oacute; quy m&ocirc; lớn.</li>
</ul>

V&igrave; vậy, với những trường hợp phức tạp hơn, thay v&igrave; kết nối trực tiếp hay d&ugrave;ng một ESB trung t&acirc;m, ch&uacute;ng ta c&oacute; thể sử dụng 1&nbsp;messaging bus&nbsp;trung t&acirc;m gọn nhẹ. N&oacute; cung cấp một lớp trừu tượng h&oacute;a c&aacute;c microservices (an abstraction layer). C&aacute;ch n&agrave;y được gọi l&agrave; API Gateway.

Bạn có thể xây dựng ứng dụng mới với microservices hoặc chuyển đổi ứng dụng sẵn có sang microservices. Với cách nào thì việc quyết định kích cỡ, phạm vi và tính năng của microservices rất quan trọng. Có thể đây chính là phần khó nhất bạn gặp phải khi phát triển hệ thống microservices trong thực tế.

Microservices: Cưỡi ngựa xem hoa - Phần 2

<h2>API-Gateway</h2>

Nh&igrave;n chung, một API Gateway cho ph&eacute;p bạn sử dụng một API được quản l&yacute; qua HTTP/REST. V&igrave; thế, ch&uacute;ng ta c&oacute; thể cung cấp tất cả c&aacute;c chức năng nghiệp vụ được ph&aacute;t triển th&agrave;nh microservices qua API Gateway như một APIs tập trung được quản l&yacute;.

<img alt="" height="294" src="/ckfinder/userfiles/images/image-20220905140348-1.png" width="659" />

Trong v&iacute; dụ b&aacute;n h&agrave;ng của ch&uacute;ng ta, theo&nbsp;H&igrave;nh 5&nbsp;tất cả microservices đều được xuất ra th&ocirc;ng qua API Gateway v&agrave; đ&acirc;y l&agrave; một chốt đầu v&agrave;o duy nhất cho người d&ugrave;ng. Nếu một microservice muốn giao tiếp với một microservice kh&aacute;c th&igrave; cần đi qua API Gateway.

API Gateway cung cấp c&aacute;c lợi thế dưới đ&acirc;y:

<ul>
	<li>Cung cấp một lớp trừu tượng h&oacute;a c&aacute;c microservices. V&iacute; dụ thay v&igrave; cung cấp một API cho tất cả kh&aacute;ch h&agrave;ng, API gateway c&oacute; thể xuất ra hay hiển thị API kh&aacute;c nhau cho mỗi kh&aacute;ch h&agrave;ng.</li>
	<li>Định tuyến v&agrave; chuyển đổi tin nhắn gọn nhẹ ở cấp gateway.</li>
	<li>Một điểm tập trung cho c&aacute;c chức năng chung kh&ocirc;ng mang t&iacute;nh nghiệp vụ kinh doanh như bảo mật, gi&aacute;m s&aacute;t v&agrave; điều tiết.</li>
	<li>Với API Gateway, microservices trở n&ecirc;n c&agrave;ng gọn nhẹ v&igrave; c&aacute;c chức năng chung kh&ocirc;ng mang t&iacute;nh nghiệp vụ đều chuyển sang Gateway.</li>
</ul>

API Gateway c&oacute; thể l&agrave; kiểu mẫu được sử dụng rộng r&atilde;i nhất trong triển khai microservices.

<h2>Message Broker &ndash; Người truyền tin trung gian</h2>

Microservices c&oacute; thể được kết nối qua truyền tin bất đồng bộ như y&ecirc;u cầu một chiều (requests) hay th&ocirc;ng b&aacute;o/ đăng k&iacute; nhận th&ocirc;ng b&aacute;o (publish/ subscribe) qua queues hay topics. Với publish/ subscribe, một service c&oacute; thể tạo tin nhắn v&agrave; gửi bất đồng bộ đến một h&agrave;ng chờ (queue hay topic). Sau đ&oacute; service kh&aacute;c c&oacute; thể nhận tin n&agrave;y từ queue hay topic. Phong c&aacute;ch n&agrave;y t&aacute;ch biệt người gửi v&agrave; người nhận, v&agrave; người truyền tin trung gian sẽ lưu tin nhắn đến khi người nhận c&oacute; thể xử l&yacute;. Người gửi ho&agrave;n to&agrave;n kh&ocirc;ng biết g&igrave; về người nhận.

<img alt="" height="286" src="/ckfinder/userfiles/images/image-20220905140401-2.png" width="658" />

Giao tiếp giữa người gửi/ người nhận được tạo ra bởi&nbsp;message broker&nbsp;qua c&aacute;c ti&ecirc;u chuẩn truyền tin bất đồng bộ như AMQP, MQTT,&hellip;

<h2>Quản L&yacute; Cơ Sở Dữ Liệu Ph&acirc;n T&aacute;n</h2>

Trong cấu tr&uacute;c monolithic, ứng dụng lưu dữ liệu v&agrave;o một cơ sở dữ liệu (CSDL) tập trung duy nhất.

<img alt="" height="265" src="/ckfinder/userfiles/images/image-20220905140421-3.png" width="419" />

Trong microservices, c&aacute;c chức năng được t&aacute;ch th&agrave;nh nhiều microservices v&agrave; nếu sử dụng c&ugrave;ng một CSDL trung t&acirc;m th&igrave; microservices kh&ocirc;ng c&ograve;n độc lập. Thay đổi dữ liệu của một service c&oacute; thể l&agrave;m hỏng c&aacute;c services kh&aacute;c. Do đ&oacute;, mỗi microservice phải c&oacute; CSDL ri&ecirc;ng.

<img alt="" height="249" src="/ckfinder/userfiles/images/image-20220905140439-4.png" width="413" />

Dưới đ&acirc;y l&agrave; v&agrave;i đặc điểm ch&iacute;nh khi ph&aacute;t triển việc quản l&yacute; dữ liệu ph&acirc;n t&aacute;n trong kiến tr&uacute;c microservices.

<ul>
	<li>Mỗi service c&oacute; thể c&oacute; một CSDL ri&ecirc;ng biệt để lưu trữ th&ocirc;ng tin cần thiết cho nghiệp vụ của service đ&oacute;.</li>
	<li>Một microservice chỉ c&oacute; thể truy xuất v&agrave;o CSDL ri&ecirc;ng của n&oacute; m&agrave; kh&ocirc;ng c&oacute; quyền truy xuất v&agrave;o CSDL của microservices kh&aacute;c.</li>
	<li>Trong một số ho&agrave;n cảnh, để ho&agrave;n th&agrave;nh một t&aacute;c vụ bạn cần phải cập nhật nhiều CSDL. Khi đ&oacute; CSDL của microservices kh&aacute;c chỉ n&ecirc;n được cập nhật qua API của những dịch vụ n&agrave;y (kh&ocirc;ng trực tiếp thay đổi CSDL).</li>
</ul>

Việc ph&acirc;n t&aacute;ch quản l&yacute; dữ liệu cho ph&eacute;p bạn ho&agrave;n to&agrave;n ph&acirc;n t&aacute;ch c&aacute;c microservices v&agrave; c&oacute; thể chọn c&aacute;c c&ocirc;ng nghệ quản l&yacute; dữ liệu kh&aacute;c nhau (SQL hay NoSQL,&hellip;nhiều CSDL kh&aacute;c nhau cho c&aacute;c microservices). Tuy nhi&ecirc;n, với c&aacute;c giao dịch phức tạp li&ecirc;n quan đến nhiều microservices, giao dịch phải được thực hiện qua API.

Ý tưởng chính của API Gateway là sử dụng một cổng truyền tin gọn nhẹ như một điểm vào chính cho tất cả khách hàng/ người dùng và triển khai những chức năng chung mà không liên quan đến nghiệp vụ đặc thù ở cấp Gateway này.

Microservices: Cưỡi ngựa xem hoa - Phần 3 (API-Gateway)

&lt;html&gt;&lt;body&gt;&lt;pre&gt;&lt;code class=&quot;language-c&quot;&gt;Quản Trị Ph&acirc;n T&aacute;n&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Kiến tr&uacute;c microservices ủng hộ quản trị ph&acirc;n t&aacute;n.&lt;/p&gt;&lt;p&gt;Nh&igrave;n chung, quản trị nghĩa l&agrave; thiết lập v&agrave; thực thi phương thức m&agrave; con người v&agrave; c&aacute;c giải ph&aacute;p l&agrave;m việc c&ugrave;ng nhau để đạt được mục ti&ecirc;u. Trong ngữ cảnh SOA, quản trị SOA (SOA governance) hướng dẫn việc ph&aacute;t triển c&aacute;c services c&oacute; thể t&aacute;i sử dụng, thiết lập c&aacute;ch services được thiết kế, ph&aacute;t triển v&agrave; c&aacute;ch ch&uacute;ng thay đổi theo thời gian. N&oacute; thiết lập một giao k&egrave;o giữa người cung cấp services v&agrave; người sử dụng services, th&ocirc;ng b&aacute;o cho người sử dụng những thứ họ c&oacute; thể nhận được v&agrave; người sử dụng những thứ họ phải cung cấp. Trong quản trị SOA, c&oacute; hai kiểu quản trị phổ biến:&lt;/p&gt;&lt;ul&gt;&lt;li&gt;Quản trị khi thiết kế &ndash; định nghĩa v&agrave; kiểm so&aacute;t việc tạo services, thiết kế v&agrave; thực thi c&aacute;c ch&iacute;nh s&aacute;ch của services.&lt;/li&gt;&lt;li&gt;Quản trị khi triển khai/ chạy &ndash; khả năng đảm bảo c&aacute;c ch&iacute;nh s&aacute;ch của services trong qu&aacute; tr&igrave;nh hoạt động.&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;&lt;i&gt;Vậy trong microservices th&igrave; quản trị l&agrave; g&igrave;?&lt;/i&gt;&lt;/p&gt;&lt;p&gt;Microservices được x&acirc;y dựng động lập v&agrave; ph&acirc;n t&aacute;n với nền tảng c&ocirc;ng nghệ kh&aacute;c nhau. Do đ&oacute;, việc thiết lập một ti&ecirc;u chuẩn thiết kế v&agrave; ph&aacute;t triển chung l&agrave; kh&ocirc;ng cần thiết. Ch&uacute;ng ta c&oacute; thể kết luận về khả năng quản trị ph&acirc;n t&aacute;n trong kiến tr&uacute;c microservices như sau:&lt;/p&gt;&lt;ul&gt;&lt;li&gt;Kh&ocirc;ng cần phải c&oacute; một hệ quản trị tập trung khi thiết kế.&lt;/li&gt;&lt;li&gt;Microservices c&oacute; thể tự quyết định thiết kế v&agrave; ph&aacute;t triển của n&oacute;.&lt;/li&gt;&lt;li&gt;Kiến tr&uacute;c ủng hộ v&agrave; hỗ trợ việc chia sẻ c&aacute;c services chung hay c&oacute; thể t&aacute;i sử dụng.&lt;/li&gt;&lt;li&gt;Một số mặt của quản trị trong qu&aacute; tr&igrave;nh hoạt động như SLAs, điều phối, gi&aacute;m s&aacute;t, bảo mật hay t&igrave;m kiếm dịch vụ (service discovery) c&oacute; thể được ph&aacute;t triển ở cấp API Gateway.&lt;/li&gt;&lt;/ul&gt;&lt;h3&gt;&lt;strong&gt;Service Registry &amp;amp; Service Discorvery (Truy T&igrave;m Dịch Vụ).&lt;/strong&gt;&lt;/h3&gt;&lt;p&gt;Trong microservices, số lượng services m&agrave; bạn cần xử l&yacute; kh&aacute; lớn. V&agrave; địa điểm của ch&uacute;ng c&oacute; thể thay đổi nhanh v&agrave; thường xuy&ecirc;n v&igrave; t&iacute;nh chất của việc ph&aacute;t triển microservices l&agrave; nhanh. N&ecirc;n bạn cần phải x&aacute;c định được vị tr&iacute; của một service trong qu&aacute; tr&igrave;nh chạy. Giải ph&aacute;p cho vấn đề n&agrave;y l&agrave; Service Registry.&lt;/p&gt;&lt;h3&gt;&lt;strong&gt;Service Registry&lt;/strong&gt;&lt;/h3&gt;&lt;p&gt;Service Registry giữ c&aacute;c thực thể microservices v&agrave; địa chỉ của ch&uacute;ng. Thực thể microservices được đăng k&iacute; với service registery khi bắt đầu chạy v&agrave; hủy đăng k&iacute; khi tắt. Người d&ugrave;ng c&oacute; thể t&igrave;m c&aacute;c services đang tồn tại v&agrave; địa chỉ của ch&uacute;ng qua service registry.&lt;/p&gt;&lt;h3&gt;&lt;strong&gt;Service Discovery&lt;/strong&gt;&lt;/h3&gt;&lt;p&gt;Để t&igrave;m c&aacute;c microservices đang tồn tại v&agrave; địa điểm của ch&uacute;ng, ch&uacute;ng ta cần một quy tr&igrave;nh truy t&igrave;m dịch vụ. C&oacute; hai m&ocirc; h&igrave;nh l&agrave; Client-side Discovery v&agrave; Server-side Discovery. H&atilde;y c&ugrave;ng xem x&eacute;t hai m&ocirc; h&igrave;nh n&agrave;y.&lt;/p&gt;&lt;p&gt;&lt;i&gt;Client-side Discovery&lt;/i&gt;&nbsp;&ndash; Với m&ocirc; h&igrave;nh n&agrave;y, client hay API Gateway lấy th&ocirc;ng tin địa điểm của một thực thể service bằng c&aacute;ch truy vấn Service Registry.&lt;/p&gt;&lt;p style=&quot;text-align:center;&quot;&gt;&lt;img src=&quot;https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-dU8E9DeAowxJUvH7iVz4fjcjUHZE4xeUtfavIeEh.png&quot; alt=&quot;&quot;&gt;&lt;/p&gt;&lt;p&gt;Client hay API Gateway phải thực hiện logic t&igrave;m kiếm service bằng c&aacute;ch gọi v&agrave;o Service Registry.&lt;/p&gt;&lt;p&gt;&lt;i&gt;Server-side Discovery &ndash;&lt;/i&gt;&nbsp;Với c&aacute;ch n&agrave;y, client hay API Gateway gửi y&ecirc;u cầu l&ecirc;n một component (c&oacute; thể l&agrave; một Load Balancer). Component n&agrave;y sẽ gọi Service Registry v&agrave; quyết định địa điểm của c&aacute;c microservices.&lt;/p&gt;&lt;p style=&quot;text-align:center;&quot;&gt;&lt;img src=&quot;https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-IhnnuxS99BATpwpcuEKQmgRNUrpZyFBmb3uaZu9d.png&quot; alt=&quot;&quot;&gt;&lt;/p&gt;&lt;p&gt;Một số giải ph&aacute;p triển khai microservices như Kubernetes cung cấp m&ocirc; h&igrave;nh server-side discovery.&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;

Quản Trị Phân Tán, Service Registry & Service Discorvery (Truy Tìm Dịch Vụ), Service Registry, Service Discovery

Microservices: Cưỡi ngựa xem hoa - Phần 4

<h2>Deployment&nbsp;&ndash;&nbsp;Triển&nbsp;Khai Updated</h2>

Việc triển khai c&aacute;c dịch vụ c&oacute; một tr&ograve; trọng yếu v&agrave; gồm c&aacute;c y&ecirc;u cầu sau:

<ul>
	<li>Khả năng triển khai/ gỡ xuống độc lập m&agrave; kh&ocirc;ng ảnh hưởng đến dịch vụ kh&aacute;c.</li>
	<li>C&oacute; thể mở rộng theo cấp microservices, chỉ mở rộng microservices cần thiết.</li>
	<li>Ph&aacute;t triển v&agrave; triển khai microservices nhanh ch&oacute;ng.</li>
	<li>Một microservice ngắt kết nối hay sập th&igrave; kh&ocirc;ng ảnh hưởng c&aacute;c dịch vụ kh&aacute;c.</li>
</ul>

Docker&nbsp;(một c&ocirc;ng cụ m&atilde; nguồn mở cho ph&eacute;p lập tr&igrave;nh vi&ecirc;n v&agrave; quản trị vi&ecirc;n hệ thống triển khai c&aacute;c ứng dụng th&agrave;nh c&aacute;c containers tr&ecirc;n m&ocirc;i trường Linux) cung cấp một c&ocirc;ng cụ tuyệt vời để triển khai microservices đ&aacute;p ứng đủ c&aacute;c y&ecirc;u cầu tr&ecirc;n. C&aacute;c bước ch&iacute;nh gồm:

<ul>
	<li>Đ&oacute;ng g&oacute;i mỗi microservice th&agrave;nh một ảnh Docker (docker image).</li>
	<li>Triển khai mỗi thực thể của service l&agrave; một Docker container.</li>
	<li>Mở rộng dựa v&agrave;o số lượng thực thể.</li>
	<li>Ph&aacute;t triển, triển khai v&agrave; khởi động microservices trở n&ecirc;n nhanh hơn với Docker (nhanh hơn nhiều c&aacute;c m&aacute;y ảo th&ocirc;ng thường &ndash; VM).</li>
</ul>

Kubernetes&nbsp;mở rộng khả năng của Docker bằng c&aacute;ch quản l&yacute; một cụm c&aacute;c Linux container như một hệ thống duy nhất, quản l&yacute; v&agrave; chạy c&aacute;c Docker containers tr&ecirc;n nhiều hosts, cung cấp service discovery v&agrave; kiểm so&aacute;t việc nh&acirc;n rộng. Như bạn c&oacute; thể thấy, những t&iacute;nh năng n&agrave;y cần thiết cho kiến tr&uacute;c microservices. V&igrave; vậy sử dụng&nbsp;Kurbernetes&nbsp;(tr&ecirc;n nền Docker) để triển khai microservices đang trở th&agrave;nh một phương ph&aacute;p cực k&igrave; hữu dụng, đặc biệt với ứng dụng lớn.

<img alt="" height="419" src="/ckfinder/userfiles/images/image-20220905140709-1.png" width="382" />

H&igrave;nh 11&nbsp;thể hiện tổng qu&aacute;t việc triển khai c&aacute;c microservices. Mỗi thực thể của microservices được triển khai th&agrave;nh một container v&agrave; c&oacute; hai containers tr&ecirc;n mỗi host. Bạn c&oacute; thể thay đổi số lượng containers chạy tr&ecirc;n một host theo &yacute; m&igrave;nh.

<h2>Security &ndash; Bảo Mật</h2>

Bảo mật microservcies l&agrave; một y&ecirc;u cầu phổ biến trong thực tế. Trước khi n&oacute;i đến bảo mật microservices, h&atilde;y nh&igrave;n lại c&aacute;ch ch&uacute;ng ta thường thực hiện bảo mật của ứng dụng monolithic.

<ul>
	<li>Bảo mật của một ứng dụng monolithic thường l&agrave; về x&aacute;c định xem &ldquo;Ai l&agrave; người gọi đến&rdquo;, &ldquo;Người n&agrave;y c&oacute; quyền hạn g&igrave;&rdquo; v&agrave; &ldquo;Ứng dụng th&ocirc;ng b&aacute;o về những th&ocirc;ng tin n&agrave;y thế n&agrave;o&rdquo;.</li>
	<li>Một component phụ tr&aacute;ch bảo mật chung thường nằm ở đầu chuỗi xử l&yacute; y&ecirc;u cầu v&agrave; component sẽ trả về th&ocirc;ng tin cần thiết.</li>
</ul>

Vậy ch&uacute;ng ta c&oacute; thể chuyển đổi trực tiếp m&ocirc; h&igrave;nh n&agrave;y sang kiến tr&uacute;c microservices kh&ocirc;ng?

C&oacute; nhưng điều n&agrave;y y&ecirc;u cầu ph&aacute;t triển bảo mật ở từng microservices v&agrave; kết nối với một cơ sở trung t&acirc;m về người d&ugrave;ng để lấy th&ocirc;ng tin cần thiết. Đ&acirc;y l&agrave; một c&aacute;ch kh&aacute; rối rắm. Thay v&agrave;o đ&oacute;, ch&uacute;ng ta c&oacute; thể tận dụng c&aacute;c API bảo mật ti&ecirc;u chuẩn như OAuth2 v&agrave; OpenID Connect để t&igrave;m một giải ph&aacute;p tốt hơn cho vấn đề bảo mật. Trước khi n&oacute;i s&acirc;u hơn, ch&uacute;ng ta sẽ t&oacute;m tắt mục ti&ecirc;u của mỗi ti&ecirc;u chuẩn v&agrave; c&aacute;ch sử dụng ch&uacute;ng.

<ul>
	<li>OAuth2&nbsp;&ndash; một phương thức chứng thực kiểu ủy quyền. Client x&aacute;c thực với server cấp quyền (authorization server) v&agrave; nhận một token gọi l&agrave; &ldquo;Access token&rdquo;. Access token kh&ocirc;ng chứa bất k&igrave; th&ocirc;ng tin g&igrave; về client. N&oacute; chỉ l&agrave; một tấm v&eacute; tham chiếu đến th&ocirc;ng tin người d&ugrave;ng m&agrave; server cấp quyền c&oacute; thể truy xuất đến. Do đ&oacute;, đ&acirc;y cũng được gọi l&agrave; token kiểu tham chiếu &ldquo;by-reference token&rdquo; v&agrave; an to&agrave;n để sử dụng tr&ecirc;n mạng lưới mở v&agrave; internet.</li>
	<li>OpenID&nbsp;Connect&nbsp;hoạt động tương tự OAuth nhưng ngo&agrave;i Access Token, server cấp quyền c&ograve;n ph&aacute;t một ID token chứa th&ocirc;ng tin người d&ugrave;ng. Token n&agrave;y thường dạng JWT (JSON Web Token) v&agrave; được k&iacute; bởi server cấp quyền. JWT token do đ&oacute; được coi l&agrave; token kiểu tham trị &ldquo;by-value token&rdquo; bởi v&igrave; n&oacute; chứa th&ocirc;ng tin về người d&ugrave;ng v&agrave; c&oacute; thể trở n&ecirc;n kh&ocirc;ng an to&agrave;n.</li>
</ul>

B&acirc;y giờ, h&atilde;y xem x&eacute;t những ti&ecirc;u chuẩn n&agrave;y c&oacute; thể bảo mật microservices trong v&iacute; dụ b&aacute;n h&agrave;ng của ch&uacute;ng ta như thế n&agrave;o.

<img alt="" height="346" src="/ckfinder/userfiles/images/image-20220905140749-2.png" width="759" />

Như h&igrave;nh tr&ecirc;n, c&aacute;c bước ch&iacute;nh để thực hiện bảo mật microservices gồm:

<ul>
	<li>Chuyển việc x&aacute;c thực cho server dạng OAuth v&agrave; OpenID Connect (Authorization server).</li>
	<li>Sử dụng API Gateway để c&oacute; một điểm đầu v&agrave;o duy nhất cho y&ecirc;u cầu từ clients.</li>
	<li>Client kết nối với server cấp quyền v&agrave; nhận Access token. Sau đ&oacute; gửi token n&agrave;y đến API Gateway c&ugrave;ng với y&ecirc;u cầu.</li>
	<li>Dịch token tại Gateway &ndash; API Gateway lấy ra access token v&agrave; gửi đến server cấp quyền để lấy JWT.</li>
	<li>Gateway truyền JWT c&ugrave;ng với y&ecirc;u cầu đến microservices.</li>
	<li>JWT chứa th&ocirc;ng tin người d&ugrave;ng cần thiết để lưu user sessions,&hellip;.</li>
	<li>Ở mỗi lớp microservice, bạn c&oacute; thể c&oacute; một component xử l&yacute; JWT, việc n&agrave;y kh&aacute;c đơn giản. 
	https://lh4.googleusercontent.com/JDjSmaNIR-Px5svzdyVwpGd9B6S8vaCt0sWMxGjpkHOm-u6Q4lmJhVrRwq3oz8MGu3QrfyqjrrDo4CZUtgIa6d97ig</li>
</ul>

Deployment – Triển Khai và Security - Bảo mật trong kiến trúc Microservices.

Microservices: Cưỡi ngựa xem hoa - Phần 5

&lt;html&gt;&lt;body&gt;&lt;h2&gt;&lt;strong&gt;Transactions&nbsp;&ndash; C&aacute;c giao dịch Updated Again&lt;/strong&gt;&lt;/h2&gt;&lt;p&gt;&lt;i&gt;C&aacute;c transactions (giao dịch) trong microservices được hỗ trợ thế n&agrave;o (Updated) ?&lt;/i&gt;&lt;/p&gt;&lt;h6&gt;&lt;img src=&quot;https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-SwW5F8BxhBiT42Xmstbtq4JYFvW4lWo2TpOGt4gz.png&quot;&gt;&lt;/h6&gt;&lt;figure class=&quot;image&quot;&gt;&lt;img src=&quot;https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-b18onTW5VKQx5jfv8rW4eFkcgyxM5MNkXOoHzS0L.png&quot;&gt;&lt;figcaption&gt;captionnnnn&lt;/figcaption&gt;&lt;/figure&gt;&lt;p&gt;Tr&ecirc;n thực tế, hỗ trợ c&aacute;c giao dịch ph&acirc;n t&aacute;n tr&ecirc;n nhiều microservices l&agrave; một nhiệm vụ đặc biệt phức tạp. Kiến tr&uacute;c microservice tự khuyến kh&iacute;ch sự phối hợp kh&ocirc;ng c&oacute; giao dịch giữa c&aacute;c dịch vụ.&lt;/p&gt;&lt;p&gt;&Yacute; tưởng l&agrave; một dịch vụ nhất định ho&agrave;n to&agrave;n kh&eacute;p k&iacute;n v&agrave; dựa tr&ecirc;n nguy&ecirc;n l&yacute; Single Responsibility Principle.&lt;/p&gt;&lt;p&gt;&nbsp;&lt;/p&gt;&lt;p&gt;Việc cần phải c&oacute; c&aacute;c giao dịch ph&acirc;n t&aacute;n tr&ecirc;n nhiều microservice thường l&agrave; một triệu chứng của lỗ hổng thiết kế trong kiến ​​tr&uacute;c microservice v&agrave; thường c&oacute; thể được sắp xếp bằng c&aacute;ch t&aacute;i cấu tr&uacute;c phạm vi của microservice.&lt;/p&gt;&lt;p&gt;Tuy nhi&ecirc;n, nếu c&oacute; một y&ecirc;u cầu bắt buộc l&agrave; phải c&oacute; c&aacute;c giao dịch ph&acirc;n t&aacute;n tr&ecirc;n nhiều dịch vụ, th&igrave; c&aacute;c kịch bản như vậy c&oacute; thể được thực hiện với &lsquo;compensating operations&rsquo; (c&aacute;c hoạt động b&ugrave; ) ở cấp độ mỗi dịch vụ.&lt;/p&gt;&lt;p&gt;&Yacute; tưởng ch&iacute;nh l&agrave;, một microservice cụ thể dựa tr&ecirc;n nguy&ecirc;n l&yacute; Single Responsibility Principle v&agrave; nếu một microservice n&agrave;o đ&oacute; kh&ocirc;ng thực hiện được nhiệm vụ đ&atilde; giao, ch&uacute;ng ta c&oacute; thể coi đ&oacute; l&agrave; một thất bại của to&agrave;n bộ microservice đ&oacute;. Sau đ&oacute;, tất cả c&aacute;c hoạt động kh&aacute;c&nbsp;&lt;br&gt;(c&aacute;c hoạt động ở cấp tr&ecirc;n) phải được ho&agrave;n t&aacute;c bằng c&aacute;ch gọi hoạt động b&ugrave; tương ứng của c&aacute;c dịch vụ si&ecirc;u nhỏ đ&oacute;.&lt;/p&gt;&lt;h2&gt;&lt;strong&gt;Design for Failures &ndash; Thiết Kế Cho C&aacute;c Thất Bại&lt;/strong&gt;&lt;/h2&gt;&lt;p&gt;Kiến tr&uacute;c microservices tăng khả năng xảy ra thất bại tại microservices. Một microservice c&oacute; thể sập do một vấn đề mạng, nguồn t&agrave;i nguy&ecirc;n bị thiếu hụt hoặc kh&ocirc;ng sẵn s&agrave;ng,&hellip; Một microservice kh&ocirc;ng đ&aacute;p ứng lại th&igrave; kh&ocirc;ng n&ecirc;n dẫn đến to&agrave;n bộ ứng dụng microservices sập. Do đ&oacute;, mỗi microservices n&ecirc;n c&oacute; khả năng chịu lỗi v&agrave; hồi phục khi c&oacute; thể. Người d&ugrave;ng phải c&oacute; trải nghiệm tốt, nhẹ nh&agrave;ng v&agrave; kh&ocirc;ng nhận ra lỗi b&ecirc;n trong hệ thống.&lt;/p&gt;&lt;p&gt;Th&ecirc;m nữa, v&igrave; c&aacute;c dịch vụ c&oacute; thể gặp lỗi bất cứ l&uacute;c n&agrave;o, việc ph&aacute;t hiện (gi&aacute;m s&aacute;t thời gian thực) lỗi nhanh ch&oacute;ng v&agrave; nếu c&oacute; thể tự động phục hồi dịch vụ l&agrave; cực k&igrave; quan trọng.&lt;/p&gt;&lt;p&gt;C&oacute; một v&agrave;i kiểu mẫu xử l&yacute; lỗi trong microservices phổ biến.&lt;/p&gt;&lt;h3&gt;&lt;i&gt;&lt;strong&gt;Circuit Breaker&lt;/strong&gt;&lt;/i&gt;&lt;/h3&gt;&lt;p&gt;Khi c&oacute; lời gọi từ b&ecirc;n ngo&agrave;i đến một microservice, bạn c&oacute; thể cấu h&igrave;nh một component gi&aacute;m s&aacute;t lỗi với mỗi lời gọi. Component n&agrave;y đếm số y&ecirc;u cầu th&agrave;nh c&ocirc;ng v&agrave; thất bại, khi lỗi đạt một giới hạn nhất định th&igrave; component n&agrave;y sẽ dừng hoạt động của service (ngắt giao mạch).&lt;/p&gt;&lt;p&gt;C&aacute;ch n&agrave;y hữu dụng để tr&aacute;nh ti&ecirc;u tốn t&agrave;i nguy&ecirc;n kh&ocirc;ng cần thiết, y&ecirc;u cầu bị chậm v&igrave; timeouts, c&aacute;ch n&agrave;y cũng gi&uacute;p gi&aacute;m s&aacute;t hệ thống.&lt;/p&gt;&lt;h3&gt;&lt;i&gt;&lt;strong&gt;Bulkhead&lt;/strong&gt;&lt;/i&gt;&lt;/h3&gt;&lt;p&gt;V&igrave; một ứng dụng kiến tr&uacute;c microservices bao gồm nhiều microservices, một service dừng hoạt động kh&ocirc;ng n&ecirc;n ảnh hưởng đến phần c&ograve;n lại. Kiểu mẫu bulkhead t&aacute;ch biệt c&aacute;c phần của ứng dụng để khi c&oacute; lỗi tại một nơi n&agrave;o đ&oacute; th&igrave; kh&ocirc;ng ảnh hưởng hệ thống.&lt;/p&gt;&lt;h3&gt;&lt;i&gt;&lt;strong&gt;Timeout&lt;/strong&gt;&lt;/i&gt;&lt;/h3&gt;&lt;p&gt;Kiểu mẫu timeout l&agrave; một quy tr&igrave;nh cho ph&eacute;p dừng một y&ecirc;u cầu khi thời gian chờ đợi vượt qu&aacute; hạn mức. Bạn c&oacute; thể cấu h&igrave;nh khung thời gian t&ugrave;y &yacute;.&lt;/p&gt;&lt;p&gt;&lt;i&gt;Vậy khi n&agrave;o ch&uacute;ng ta sử dụng những kiểu mẫu n&agrave;y?&lt;/i&gt;&lt;/p&gt;&lt;p&gt;Trong phần lớn trường hợp, những kiểu mẫu n&agrave;y được &aacute;p dụng ở lớp Gateway. Khi microservices kh&ocirc;ng đ&aacute;p lại hay kh&ocirc;ng sẵn s&agrave;ng, ở cấp Gateway ch&uacute;ng ta c&oacute; thể quyết định c&oacute; n&ecirc;n gửi y&ecirc;u cầu đến microservices sử dụng circuit breakers hay timeout. Hơn nữa, sử dụng bulkhead ở Gateway kh&aacute; quan trọng v&igrave; đ&acirc;y l&agrave; một điểm đầu v&agrave;o cho tất cả y&ecirc;u cầu từ clients, n&ecirc;n nếu lỗi một service cũng kh&ocirc;ng ảnh hưởng đến việc gửi y&ecirc;u cầu đến c&aacute;c services kh&aacute;c.&lt;/p&gt;&lt;p&gt;Th&ecirc;m v&agrave;o đ&oacute;, Gateway c&oacute; thể được sử dụng như một điểm trung t&acirc;m ta c&oacute; thể lấy th&ocirc;ng tin về trạng th&aacute;i v&agrave; theo d&otilde;i c&aacute;c microservices hoạt động.&lt;/p&gt;&lt;h2&gt;&lt;strong&gt;Microservices, T&iacute;ch Hợp Cho Doanh Nghiệp, Quản L&yacute; API v&agrave; hơn thế nữa&lt;/strong&gt;&lt;/h2&gt;&lt;p&gt;Ch&uacute;ng ta đ&atilde; trao đổi c&aacute;c đặc t&iacute;nh của kiến tr&uacute;c Microservices v&agrave; c&aacute;ch bạn c&oacute; thể thực hiện ch&uacute;ng. Tuy nhi&ecirc;n, bạn n&ecirc;n lưu &yacute; rằng Microservices kh&ocirc;ng phải toa thuốc chữa b&aacute;ch bệnh. Việc &aacute;p dụng m&ugrave; qu&aacute;ng những kh&aacute;i niệm đang nổi sẽ kh&ocirc;ng xử l&yacute; vấn đề thực tế của bạn. Nếu bạn đ&atilde; đọc to&agrave;n bộ b&agrave;i n&agrave;y th&igrave; bạn sẽ thấy Microservices c&oacute; nhiều lợi &iacute;ch v&agrave; ch&uacute;ng ta n&ecirc;n tận dụng. Tuy nhi&ecirc;n, bạn cần hiểu rằng mong chờ microservices giải quyết tất cả c&aacute;c vấn đề l&agrave; kh&ocirc;ng thực tiễn.&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;

Transactions – Các giao dịch, Design for Failures – Thiết Kế Cho Các Thất Bại, Microservices, Tích Hợp Cho Doanh Nghiệp, Quản Lý API và hơn thế nữa.....

Microservices: Cưỡi ngựa xem hoa - Phần 6

Microservices

<html><body> <figure class="image"><img src="https://uat.admin.careers.saigontechnology.vn/storage/ck-editor/test3-T25ICQrnxro2NaWwPCayB3R810kCXdkJ0PihGzXF.jpg"></figure> <img src="https://uat.admin.careers.saigontechnology.vn/storage/ck-editor/test4-1KxwvkuMEjOIIwsFpbeciZXEEWrCYvGhmcLZlg3V.jpg"><img src="https://uat.admin.careers.saigontechnology.vn/storage/ck-editor/test3-ADj6vdTAKfoTyTqUUbnUFPA3VjCvNh9kryo0Cwi6.jpeg">Test content <figure class="image"><img src="https://uat.admin.careers.saigontechnology.vn/storage/ck-editor/test-WPx79FNyPKQi5GCQ0VjQDV4nPHrLyNltdGZp9IDA.jpg"></figure> <figure class="image"><img src="https://uat.admin.careers.saigontechnology.vn/storage/ck-editor/test2-PPwwZEHH4tvxXMCqN4xXcXs0fd49MyHjYZiEuZNl.jpg"></figure></body></html>

Cài đặt môi trường làm việc cho dự án microservices với docker, xây dựng cấu trúc ban đầu cho dự án, triển khai logging và product service, containerize cho product.service.

THỰC CHIẾN X Y DỰNG KIẾN TRÚC DỰ ÁN MICROSERVICES VÀ TRIỂN KHAI PRODUCT SERVICE (PHẦN 2)

Test content<img src="https://uat.admin.careers.saigontechnology.vn/ckfinder/userfiles/images/Screen%20Shot%202022-09-22%20at%2015_32_11.png" alt="" height="160" width="256">

Test articlescsvsvsv

<html><body><h2>Transactions – Các giao dịch Updated Again</h2>Các transactions (giao dịch) trong microservices được hỗ trợ thế nào (Updated) ?<h6><img src="https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-SwW5F8BxhBiT42Xmstbtq4JYFvW4lWo2TpOGt4gz.png"></h6><figure class="image"><img src="https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-b18onTW5VKQx5jfv8rW4eFkcgyxM5MNkXOoHzS0L.png"><figcaption>captionnnnn</figcaption></figure>Trên thực tế, hỗ trợ các giao dịch phân tán trên nhiều microservices là một nhiệm vụ đặc biệt phức tạp. Kiến trúc microservice tự khuyến khích sự phối hợp không có giao dịch giữa các dịch vụ.Ý tưởng là một dịch vụ nhất định hoàn toàn khép kín và dựa trên nguyên lý Single Responsibility Principle. Việc cần phải có các giao dịch phân tán trên nhiều microservice thường là một triệu chứng của lỗ hổng thiết kế trong kiến ​​trúc microservice và thường có thể được sắp xếp bằng cách tái cấu trúc phạm vi của microservice.Tuy nhiên, nếu có một yêu cầu bắt buộc là phải có các giao dịch phân tán trên nhiều dịch vụ, thì các kịch bản như vậy có thể được thực hiện với ‘compensating operations’ (các hoạt động bù ) ở cấp độ mỗi dịch vụ.Ý tưởng chính là, một microservice cụ thể dựa trên nguyên lý Single Responsibility Principle và nếu một microservice nào đó không thực hiện được nhiệm vụ đã giao, chúng ta có thể coi đó là một thất bại của toàn bộ microservice đó. Sau đó, tất cả các hoạt động khác  (các hoạt động ở cấp trên) phải được hoàn tác bằng cách gọi hoạt động bù tương ứng của các dịch vụ siêu nhỏ đó.<h2>Design for Failures – Thiết Kế Cho Các Thất Bại</h2>Kiến trúc microservices tăng khả năng xảy ra thất bại tại microservices. Một microservice có thể sập do một vấn đề mạng, nguồn tài nguyên bị thiếu hụt hoặc không sẵn sàng,… Một microservice không đáp ứng lại thì không nên dẫn đến toàn bộ ứng dụng microservices sập. Do đó, mỗi microservices nên có khả năng chịu lỗi và hồi phục khi có thể. Người dùng phải có trải nghiệm tốt, nhẹ nhàng và không nhận ra lỗi bên trong hệ thống.Thêm nữa, vì các dịch vụ có thể gặp lỗi bất cứ lúc nào, việc phát hiện (giám sát thời gian thực) lỗi nhanh chóng và nếu có thể tự động phục hồi dịch vụ là cực kì quan trọng.Có một vài kiểu mẫu xử lý lỗi trong microservices phổ biến.<h3>Circuit Breaker</h3>Khi có lời gọi từ bên ngoài đến một microservice, bạn có thể cấu hình một component giám sát lỗi với mỗi lời gọi. Component này đếm số yêu cầu thành công và thất bại, khi lỗi đạt một giới hạn nhất định thì component này sẽ dừng hoạt động của service (ngắt giao mạch).Cách này hữu dụng để tránh tiêu tốn tài nguyên không cần thiết, yêu cầu bị chậm vì timeouts, cách này cũng giúp giám sát hệ thống.<h3>Bulkhead</h3>Vì một ứng dụng kiến trúc microservices bao gồm nhiều microservices, một service dừng hoạt động không nên ảnh hưởng đến phần còn lại. Kiểu mẫu bulkhead tách biệt các phần của ứng dụng để khi có lỗi tại một nơi nào đó thì không ảnh hưởng hệ thống.<h3>Timeout</h3>Kiểu mẫu timeout là một quy trình cho phép dừng một yêu cầu khi thời gian chờ đợi vượt quá hạn mức. Bạn có thể cấu hình khung thời gian tùy ý.Vậy khi nào chúng ta sử dụng những kiểu mẫu này?Trong phần lớn trường hợp, những kiểu mẫu này được áp dụng ở lớp Gateway. Khi microservices không đáp lại hay không sẵn sàng, ở cấp Gateway chúng ta có thể quyết định có nên gửi yêu cầu đến microservices sử dụng circuit breakers hay timeout. Hơn nữa, sử dụng bulkhead ở Gateway khá quan trọng vì đây là một điểm đầu vào cho tất cả yêu cầu từ clients, nên nếu lỗi một service cũng không ảnh hưởng đến việc gửi yêu cầu đến các services khác.Thêm vào đó, Gateway có thể được sử dụng như một điểm trung tâm ta có thể lấy thông tin về trạng thái và theo dõi các microservices hoạt động.<h2>Microservices, Tích Hợp Cho Doanh Nghiệp, Quản Lý API và hơn thế nữa</h2>Chúng ta đã trao đổi các đặc tính của kiến trúc Microservices và cách bạn có thể thực hiện chúng. Tuy nhiên, bạn nên lưu ý rằng Microservices không phải toa thuốc chữa bách bệnh. Việc áp dụng mù quáng những khái niệm đang nổi sẽ không xử lý vấn đề thực tế của bạn. Nếu bạn đã đọc toàn bộ bài này thì bạn sẽ thấy Microservices có nhiều lợi ích và chúng ta nên tận dụng. Tuy nhiên, bạn cần hiểu rằng mong chờ microservices giải quyết tất cả các vấn đề là không thực tiễn.</body></html>

JWT chứa thông tin người dùng cần thiết để lưu user sessions,….

<h2>Deployment – Triển Khai Updated</h2>

Việc triển khai các dịch vụ có một trò trọng yếu và gồm các yêu cầu sau:

<ul>
	<li>Khả năng triển khai/ gỡ xuống độc lập mà không ảnh hưởng đến dịch vụ khác.</li>
	<li>Có thể mở rộng theo cấp microservices, chỉ mở rộng microservices cần thiết.</li>
	<li>Phát triển và triển khai microservices nhanh chóng.</li>
	<li>Một microservice ngắt kết nối hay sập thì không ảnh hưởng các dịch vụ khác.</li>
</ul>

Docker (một công cụ mã nguồn mở cho phép lập trình viên và quản trị viên hệ thống triển khai các ứng dụng thành các containers trên môi trường Linux) cung cấp một công cụ tuyệt vời để triển khai microservices đáp ứng đủ các yêu cầu trên. Các bước chính gồm:

<ul>
	<li>Đóng gói mỗi microservice thành một ảnh Docker (docker image).</li>
	<li>Triển khai mỗi thực thể của service là một Docker container.</li>
	<li>Mở rộng dựa vào số lượng thực thể.</li>
	<li>Phát triển, triển khai và khởi động microservices trở nên nhanh hơn với Docker (nhanh hơn nhiều các máy ảo thông thường – VM).</li>
</ul>

Kubernetes mở rộng khả năng của Docker bằng cách quản lý một cụm các Linux container như một hệ thống duy nhất, quản lý và chạy các Docker containers trên nhiều hosts, cung cấp service discovery và kiểm soát việc nhân rộng. Như bạn có thể thấy, những tính năng này cần thiết cho kiến trúc microservices. Vì vậy sử dụng Kurbernetes (trên nền Docker) để triển khai microservices đang trở thành một phương pháp cực kì hữu dụng, đặc biệt với ứng dụng lớn.

<img alt="" height="419" src="/ckfinder/userfiles/images/image-20220905140709-1.png" width="382" />

Hình 11 thể hiện tổng quát việc triển khai các microservices. Mỗi thực thể của microservices được triển khai thành một container và có hai containers trên mỗi host. Bạn có thể thay đổi số lượng containers chạy trên một host theo ý mình.

<h2>Security – Bảo Mật</h2>

Bảo mật microservcies là một yêu cầu phổ biến trong thực tế. Trước khi nói đến bảo mật microservices, hãy nhìn lại cách chúng ta thường thực hiện bảo mật của ứng dụng monolithic.

<ul>
	<li>Bảo mật của một ứng dụng monolithic thường là về xác định xem “Ai là người gọi đến”, “Người này có quyền hạn gì” và “Ứng dụng thông báo về những thông tin này thế nào”.</li>
	<li>Một component phụ trách bảo mật chung thường nằm ở đầu chuỗi xử lý yêu cầu và component sẽ trả về thông tin cần thiết.</li>
</ul>

Vậy chúng ta có thể chuyển đổi trực tiếp mô hình này sang kiến trúc microservices không?

Có nhưng điều này yêu cầu phát triển bảo mật ở từng microservices và kết nối với một cơ sở trung tâm về người dùng để lấy thông tin cần thiết. Đây là một cách khá rối rắm. Thay vào đó, chúng ta có thể tận dụng các API bảo mật tiêu chuẩn như OAuth2 và OpenID Connect để tìm một giải pháp tốt hơn cho vấn đề bảo mật. Trước khi nói sâu hơn, chúng ta sẽ tóm tắt mục tiêu của mỗi tiêu chuẩn và cách sử dụng chúng.

<ul>
	<li>OAuth2 – một phương thức chứng thực kiểu ủy quyền. Client xác thực với server cấp quyền (authorization server) và nhận một token gọi là “Access token”. Access token không chứa bất kì thông tin gì về client. Nó chỉ là một tấm vé tham chiếu đến thông tin người dùng mà server cấp quyền có thể truy xuất đến. Do đó, đây cũng được gọi là token kiểu tham chiếu “by-reference token” và an toàn để sử dụng trên mạng lưới mở và internet.</li>
	<li>OpenID Connect hoạt động tương tự OAuth nhưng ngoài Access Token, server cấp quyền còn phát một ID token chứa thông tin người dùng. Token này thường dạng JWT (JSON Web Token) và được kí bởi server cấp quyền. JWT token do đó được coi là token kiểu tham trị “by-value token” bởi vì nó chứa thông tin về người dùng và có thể trở nên không an toàn.</li>
</ul>

Bây giờ, hãy xem xét những tiêu chuẩn này có thể bảo mật microservices trong ví dụ bán hàng của chúng ta như thế nào.

<img alt="" height="346" src="/ckfinder/userfiles/images/image-20220905140749-2.png" width="759" />

Như hình trên, các bước chính để thực hiện bảo mật microservices gồm:

<ul>
	<li>Chuyển việc xác thực cho server dạng OAuth và OpenID Connect (Authorization server).</li>
	<li>Sử dụng API Gateway để có một điểm đầu vào duy nhất cho yêu cầu từ clients.</li>
	<li>Client kết nối với server cấp quyền và nhận Access token. Sau đó gửi token này đến API Gateway cùng với yêu cầu.</li>
	<li>Dịch token tại Gateway – API Gateway lấy ra access token và gửi đến server cấp quyền để lấy JWT.</li>
	<li>Gateway truyền JWT cùng với yêu cầu đến microservices.</li>
	<li>JWT chứa thông tin người dùng cần thiết để lưu user sessions,….</li>
	<li>Ở mỗi lớp microservice, bạn có thể có một component xử lý JWT, việc này khác đơn giản. 
	https://lh4.googleusercontent.com/JDjSmaNIR-Px5svzdyVwpGd9B6S8vaCt0sWMxGjpkHOm-u6Q4lmJhVrRwq3oz8MGu3QrfyqjrrDo4CZUtgIa6d97ig</li>
</ul>

<h2>API-Gateway</h2>

Nhìn chung, một API Gateway cho phép bạn sử dụng một API được quản lý qua HTTP/REST. Vì thế, chúng ta có thể cung cấp tất cả các chức năng nghiệp vụ được phát triển thành microservices qua API Gateway như một APIs tập trung được quản lý.

<img alt="" height="294" src="/ckfinder/userfiles/images/image-20220905140348-1.png" width="659" />

Trong ví dụ bán hàng của chúng ta, theo Hình 5 tất cả microservices đều được xuất ra thông qua API Gateway và đây là một chốt đầu vào duy nhất cho người dùng. Nếu một microservice muốn giao tiếp với một microservice khác thì cần đi qua API Gateway.

API Gateway cung cấp các lợi thế dưới đây:

<ul>
	<li>Cung cấp một lớp trừu tượng hóa các microservices. Ví dụ thay vì cung cấp một API cho tất cả khách hàng, API gateway có thể xuất ra hay hiển thị API khác nhau cho mỗi khách hàng.</li>
	<li>Định tuyến và chuyển đổi tin nhắn gọn nhẹ ở cấp gateway.</li>
	<li>Một điểm tập trung cho các chức năng chung không mang tính nghiệp vụ kinh doanh như bảo mật, giám sát và điều tiết.</li>
	<li>Với API Gateway, microservices trở nên càng gọn nhẹ vì các chức năng chung không mang tính nghiệp vụ đều chuyển sang Gateway.</li>
</ul>

API Gateway có thể là kiểu mẫu được sử dụng rộng rãi nhất trong triển khai microservices.

<h2>Message Broker – Người truyền tin trung gian</h2>

Microservices có thể được kết nối qua truyền tin bất đồng bộ như yêu cầu một chiều (requests) hay thông báo/ đăng kí nhận thông báo (publish/ subscribe) qua queues hay topics. Với publish/ subscribe, một service có thể tạo tin nhắn và gửi bất đồng bộ đến một hàng chờ (queue hay topic). Sau đó service khác có thể nhận tin này từ queue hay topic. Phong cách này tách biệt người gửi và người nhận, và người truyền tin trung gian sẽ lưu tin nhắn đến khi người nhận có thể xử lý. Người gửi hoàn toàn không biết gì về người nhận.

<img alt="" height="286" src="/ckfinder/userfiles/images/image-20220905140401-2.png" width="658" />

Giao tiếp giữa người gửi/ người nhận được tạo ra bởi message broker qua các tiêu chuẩn truyền tin bất đồng bộ như AMQP, MQTT,…

<h2>Quản Lý Cơ Sở Dữ Liệu Phân Tán</h2>

Trong cấu trúc monolithic, ứng dụng lưu dữ liệu vào một cơ sở dữ liệu (CSDL) tập trung duy nhất.

<img alt="" height="265" src="/ckfinder/userfiles/images/image-20220905140421-3.png" width="419" />

Trong microservices, các chức năng được tách thành nhiều microservices và nếu sử dụng cùng một CSDL trung tâm thì microservices không còn độc lập. Thay đổi dữ liệu của một service có thể làm hỏng các services khác. Do đó, mỗi microservice phải có CSDL riêng.

<img alt="" height="249" src="/ckfinder/userfiles/images/image-20220905140439-4.png" width="413" />

Dưới đây là vài đặc điểm chính khi phát triển việc quản lý dữ liệu phân tán trong kiến trúc microservices.

<ul>
	<li>Mỗi service có thể có một CSDL riêng biệt để lưu trữ thông tin cần thiết cho nghiệp vụ của service đó.</li>
	<li>Một microservice chỉ có thể truy xuất vào CSDL riêng của nó mà không có quyền truy xuất vào CSDL của microservices khác.</li>
	<li>Trong một số hoàn cảnh, để hoàn thành một tác vụ bạn cần phải cập nhật nhiều CSDL. Khi đó CSDL của microservices khác chỉ nên được cập nhật qua API của những dịch vụ này (không trực tiếp thay đổi CSDL).</li>
</ul>

Việc phân tách quản lý dữ liệu cho phép bạn hoàn toàn phân tách các microservices và có thể chọn các công nghệ quản lý dữ liệu khác nhau (SQL hay NoSQL,…nhiều CSDL khác nhau cho các microservices). Tuy nhiên, với các giao dịch phức tạp liên quan đến nhiều microservices, giao dịch phải được thực hiện qua API.

<h2>Thiết kế Microservices: kích cỡ, phạm vi và tính năng</h2>

 

Dưới đây chúng ta sẽ xem xét một số vấn đề thực tế và những hiểu sai về kích cỡ, phạm vi và chức năng của microservices.

<ul>
	<li>Số dòng code/ kích cỡ của một đội lập trình là chỉ số không chính xác: có vài cuộc bàn luận về kích thước của một service dựa vào số lượng dòng code hay kích thước của đội phát triển service đó (ví dụ <a href="http://blog.idonethis.com/two-pizza-team/">two-pizza team</a>). Tuy nhiên, những cách đo đếm này không thực tiễn và không chính xác, vì ta có thể phát triển services với ít dòng code hoặc với một đội nhỏ nhưng hoàn toàn đảm bảo được các nguyên lý trong kiến trúc microservices.</li>
	<li>“Micro” là một từ khóa dễ gây nhầm lẫn. Một số lập trình viên nghĩ rằng họ nên tạo ra services nhỏ hết mức. Điều này là một cách hiểu sai.</li>
	<li>Trong SOA, services thường trở thành các cục monolithic với nhiều hàm, chức năng khác hỗ trợ. Vì vậy, chỉ phát triển services kiểu SOA rồi dán nhãn microservices hoàn toàn lạc hướng và không mang lại bất kì lợi ích nào của kiến trúc microservices.</li>
</ul>

Do đó, câu hỏi là chúng ta nên thiết kế services trong kiến trúc microservices như thế nào thì phù hợp và đúng mực?

<h2>Một Số Chỉ Dẫn Khi Thiết Kế Microservices</h2>

<ul>
	<li>Single Responsibility Principle (SRP): một service với phạm vi và chức năng giới hạn, tập trung vào một nhiệm vụ giúp quá trình phát triển và triển khai dịch vụ trở nên nhanh chóng hơn.</li>
	<li>Trong quá trình thiết kế, ta nên xác định và giới hạn các services theo chức năng nghiệp vụ thực tế (theo <a href="http://martinfowler.com/bliki/BoundedContext.html">Domain-Driven-Design</a>).</li>
	<li>Đảm bảo microservices có thể phát triển và triển khai độc lập.</li>
	<li>Mục tiêu của thiết kế là phạm vi của microservices phục vụ một nghiệp vụ chứ không chỉ đơn giản làm các dịch vụ nhỏ hơn. Kích thước hợp lý của một service là kích thước đủ để đáp ứng yêu cầu của một chức năng trong hệ thống.</li>
	<li>Khác với services trong SOA, một microservice không nên có quá nhiều hàm hay chức năng hỗ trợ xung quanh và định dạng thông báo/ gửi tin (messaging) phải đơn giản.</li>
	<li>Một cách tốt là có thể bắt đầu với services to có phạm vi rộng rồi chia nhỏ dần (dựa theo nghiệp vụ thực tế của hệ thống).</li>
</ul>

Trong ví dụ về hệ thống bán hàng, bạn có thể thấy ứng dụng monolithic được tách thành bốn microservices là “inventory”, “accounting”, “shipping” và “store”. Chúng giải quyết một yêu cầu giới hạn nhất định nhưng tập trung vào chức năng đó. Theo đó, mỗi service tách biệt hoàn toàn khỏi nhau và đảm bảo tính linh hoạt và độc lập.

Ồ, nếu tách các services ra độc lập, vậy làm sao liên lạc và trao đổi thông tin/dữ liệu giữa các services với nhau?

<h2>Liên lạc giữa Microservices</h2>

Trong ứng dụng monolithic, các chức năng khác nhau nằm trong các component khác nhau được kết nối bằng cách gọi hàm hay phương thức. Trong SOA, việc này được chuyển sang một chế độ tách rời hơn với kiểu nhắn tin qua các dịch vụ web (web service messaging), phần lớn dùng SOAP trên nền giao thức HTTP, JMS. Những webservices này khá phức tạp. Như đã nói ở trên, microservices yêu cầu là phải có một cơ chế truyền tin đơn giản và nhẹ.

Vậy đó là những cơ chế nào?

<h2> </h2>

<h2>Gửi Tin Đồng Bộ – REST, Thrift</h2>

Với truyền tin đồng bộ (người gửi – client sẽ chờ một khoảng thời gian để nhận kết quả từ service), REST là sự lựa chọn hàng đầu vì nó cung cấp hệ thống truyền tin đơn giản qua giao thức HTTP dạng request – response. Do đó, nhiều microservices sử dụng HTTP với API. Mỗi chức năng sẽ xuất ra (expose) API.

 

Ngoài REST, Thrift cũng được sử dụng để truyền tin đồng bộ.

<h3>Gửi Tin Bất Đồng Bộ – AMQP, STOMP, MQTT</h3>

Trong một số kịch bản, truyền tin bất đồng bộ là cần thiết (client không mong đợi response ngay lập tức, hoặc không cần response). Các giao thức truyền tin bất đồng bộ như AMQP, STOMP hay MQTT được sử dụng rộng rãi.

Như vậy là chúng ta có gửi tin nhắn đồng bộ hoặc bất đồng bộ. Nhưng nên định dạng cho tin nhắn thế nào đây?

<h3>Các Định Dạng Tin Nhắn – JSON, XML, Thrift, ProtoBuf, Avro</h3>

Quyết định định dạng tin nhắn phù hợp cho microservices cũng là một yếu tố quan trọng. Với phần lớn các ứng dụng microservices, họ sử dụng những kiểu tin nhắn dạng chữ như JSON và XML trên nền giao thức HTTP với API. Trong trường hợp cần truyền tin dạng nhị phân, microservices có thể dùng dạng Thrift, Proto hay Avro.

<h3>Service Contracts – Định Nghĩa Service Interfaces – Swagger, RAML</h3>

Khi bạn có một nghiệp vụ được xây dựng như một dịch vụ, bạn cần định nghĩa và thông báo hợp đồng dịch vụ (service contract thể hiện giao kèo của service).

Bởi vì chúng ta xây dựng microservices trên kiểu kiến trúc REST, ta có thể sử dụng cùng kiểu REST API để định nghĩa hợp đồng của microservices. Do đó, microservices sử dụng các ngôn ngữ định nghĩa REST API tiêu chuẩn như Swagger, RAML để định nghĩa hợp đồng dịch vụ.

Đối với trường hợp microservices không được triển khai dựa trên HTTP/REST (cụ thể là dùng Thrift), chúng ta có thể dùng mức độ giao thức ‘Interface Definition Languages’ (ví dụ: <a href="https://thrift.apache.org/docs/idl">Thrift IDL</a>)

<h3>Kết Nối Microservices (Giao Tiếp Giữa Các Services)</h3>

Trong kiến trúc microservices, ứng dụng phần mềm được cấu thành từ các dịch vụ độc lập. Để hoàn thành một tác vụ của người dùng trên phần mềm, kết nối và giao tiếp giữa các microservices là cần thiết vì tác vụ gồm nhiều tác động khác nhau lên các services. Vì vậy, giao tiếp giữa các microservices là một vấn đề cực kì quan trọng.

Khi áp dụng SOA, giao tiếp giữa các services được tiến hành bởi một Enterprise Service Bus (ESB) và phần lớn logic nằm trong tầng trung gian này (định tuyến cho tin nhắn, chuyển đổi và điều phối tin nhắn). Tuy nhiên, kiến trúc microservices thúc đẩy việc loại trừ một tầng giao tiếp trung gian tập trung/ ESB và chuyển phần ‘smart-ness’ hay business logic sang các services (nó được gọi là ‘Smart Endpoints’).

Bởi vì microservices sử dụng giao thức tiêu chuẩn như HTTP/REST, JSON, …, Cho nên các giao tiếp giữa các microservices được cố gắng thống nhất về giao thức và hạn chế tối đa việc tích hợp với một giao thức khác. Một lựa chọn khác cho giao tiếp giữa microservices là sử dụng một message bus nhẹ hay gateway với khả năng định tuyến tối thiểu hoạt động như những đường truyền đơn thuần không xử lý business logic gì hết (dump pipe). Dựa vào những phong cách này, có một số kiểu mẫu giao tiếp trong microservices như dưới đây.

<h3>Point-to-point – Kết Nối Trực Tiếp Giữa Các Services</h3>

Với kiểu kết nối trực tiếp điểm nối điểm, toàn bộ logic của việc định tuyến truyền tin nhắn nằm trong mỗi điểm cuối (endpoint) hay chính là các services. Và services nói chuyện trực tiếp với nhau. Mỗi service mở ra một REST APIs và bất kì service hay khách hàng bên ngoài nào cũng có thể gọi service qua REST API của nó.

<img alt="" height="399" src="https://uat.admin.careers.saigontechnology.vn/ckfinder/userfiles/images/microservices-logical.png" width="987" />

Rõ ràng là mô hình này đơn giản và hoạt động ổn với ứng dụng microservices tương đối nhỏ nhưng khi số lượng services tăng lên, việc giao tiếp trở nên cực phức tạp. Đây là lý do trong mô hình SOA truyền thống người ta sử dụng Enterprise Service Bus (ESB), chính là để loại bỏ kết nối trực tiếp phức tạp và rối rắm. Sau đây là một số nhược điểm của kiểu giao tiếp trực tiếp (point to point).

<ul>
	<li>Những yêu cầu như xác thực người dùng, điều tiết, giám sát,…phải được thực hiện (implement) ở mọi microservices.</li>
	<li>Việc trên dẫn đến các tính năng phổ biến bị trùng lặp, việc thực hiện mỗi microservices có thể trở nên phức tạp.</li>
	<li>Không có cách quản lý, kiểm soát giao tiếp giữa các services (chẳng hạn như muốn theo dõi, truy tìm hay lọc các giao hành động giữa các services).</li>
	<li>Thường việc kết nối trực tiếp trong microservices được coi là <a href="https://www.infoq.com/articles/seven-uservices-antipatterns">anti-pattern</a> cho việc triển khai các ứng dụng microservice có quy mô lớn.</li>
</ul>

Vì vậy, với những trường hợp phức tạp hơn, thay vì kết nối trực tiếp hay dùng một ESB trung tâm, chúng ta có thể sử dụng 1 messaging bus trung tâm gọn nhẹ. Nó cung cấp một lớp trừu tượng hóa các microservices (an abstraction layer). Cách này được gọi là API Gateway.

<h2>Typescript khác với JavaScript thế nào</h2>

<img alt="" src="https://thangphampt.files.wordpress.com/2018/12/image-3.png" />

Có thể nói TypeScript là một phiên bản nâng cao của JavaScript vì nó bổ sung những kiểu dữ liệu tĩnh và các lớp hướng đối tượng, đồng thời nó bao gồm luôn các phiên bản ES mới nhất (tùy version của TypeScript).  
 
** ES5 = ECAMScript 5 được release năm 2009 
** ES6 = ECAMScript 6 được release năm 2015 
** Hiện tại là ES9 = ECAMScript 2018 là phiên bản Javascript mới nhất tính tại thời điểm mình viết bài này.

2. Các file TypeScript có đuôi (phần mở rộng – extension) là *.ts . Trong khi các file JS có đuôi được biết là *.js

3. Code được viết bằng TypeScript sẽ được biên dịch thành JavaScript thuần. Thường thì chúng ta sẽ dùng lệnh tsc để biên dịch vì trong TypeScript có tích hợp sẵn một trình biên dịch được viết bằng TypeScript luôn.

4. Với TypeScript chúng ta có thể khai báo biến với từ khóa: var, let và const. Trong khi var chỉ được dùng trong JS ( hình như từ ES6 trở đi JavaScript cũng dùng được var, let và const)

5. Các biến trong code TypeScript thường được dùng với kiểu dữ liệu rõ ràng hơn trong code JavaScript.

Ví dụ 1: Khai báo biến trong TypeScript

<pre>
<code>var name: string = "Thang Pham";
var isSingle: bool = true;</code></pre>

Ví dụ 2: Khai báo biến trong JavaScript

<pre>
<code>var name = "Thang Pham";
var isSingle = true;</code></pre>

6. TypeScript kiểm tra kiểu của các biến khi biên dịch code (compile time) trong khi JS kiểm tra lúc chạy (run time)

 

Ví dụ 3: TypeScript kiểm tra kiểu dữ liệu

<pre>
<code>function add(num1: number, num2: number){
 return num1 + num2;
}
add(1, 2); //3
add(1, "hai"); //error</code></pre>

Ví dụ 4: JavaScript kiểm kiểu dữ liệu

<pre>
<code>function add(num1: number, num2: number){
 return num1 + num2;
}
add(1, 2); //3
add(1, "hai"); //1hai</code></pre>

<h2>Tại sao viết code dùng Typescript thay vì dùng Javascript</h2>

<ul>
	<li>TypeScript được sử dụng để code Front-end như Angular 2 (và các phiên bản về sau), React, Ionic,… và back-end như NodeJs.</li>
	<li>TypeScript hỗ trợ đầy đủ các tính năng mà JavaScript có với các phiên bản JavaScript mới nhất (ECMAScript versions) vì như mình đã nói nó được xem như là một bản nâng cao của JS.</li>
	<li>Bạn có thể code với JS thì với qua TypeScript cũng như vậy. Vì dù sao thì code TypeScript cũng sẽ được biên dịch lại thành JS mà.</li>
	<li>TypeScript giúp bạn viết code theo phong cách OOP như: C#, Java. Nghĩa là nó có: class, abstract class, interface, encapsulation, ….</li>
	<li>Dễ dàng hơn để phát triển các dự án lớn vì nó giúp bạn kiến trúc hệ thống theo Module, namespace.</li>
	<li>Bạn sẽ dễ dàng code TypeScript khi mà nó được tích hợp trong rất nhiều IDEs như: Visual Studio Code, Sublime Text,… </li>
</ul>

Đó là những gì mình hiểu về TypeScript. Hy vọng giúp được anh em đang tìm hiểu về TypeScript có được kiến thức nền tảng.

TypeScript làm một ngôn ngữ lập trình mã nguồn mở được phát triển bởi Microsoft. Cha đẻ của TypeScript là Anders Hejlsberg, một kiến trúc sư trưởng (Lead Architect) của ngôn ngữ C# và là cha đẻ của ngôn ngữ lập trình Delphi và Turbo Pascal.

Microservices: Cưỡi ngựa xem hoa - Phần 1

Related articles

OTHER ARTICLES FROM THAO DOAN