ﺩﺭ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﻣﺎ ﻗﺼﺪ ﺩﺍﺭﻳﻢ ﺑﻪ ﺗﻮ ﺿﻴﺢ ﺍﻟﮕﻮﻱ API gateway ﺑﭙﺮﺩﺍﺯﻳﻢ ﻭ ﺍﻟﺒﺘﻪ ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﺩﺭ ﻣﻘﺎﻟﻪ ﻫﺎﻱ ﻗﺒﻞ ﺑﺎ ﺍﺭﺍﺋﻪ ﻳﻚ ﻣﺴﺌﻠﻪ ﺑﻪ ﺗﻮﺿﻴﺢ ﻣﻄﺎﻟﺐ ﻣﻲ ﭘﺮﺩﺍﺧﺘﻴﻢ ﺩﺭ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﻧﻴﺰ ﺑﺎ ﻓﺮﺽ ﺩﺍﺷﺘﻦ ﻳﻚ ﻓﺮﻭﺷﮕﺎﻩ ﺑﺰﺭﮒ ﻛﻪ ﺑﺮ ﺍﺳﺎﺱ ﻣﻌﻤﺎﺭﻱ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﺳﺖ ﺑﻪ ﺑﺮﺭﺳﻲ ﺍﻳﻦ ﺍﻟﮕﻮ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ ﻭ ﻣﻄﺎﻟﺐ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺷﺎﻣﻞ :

 ﺗﻌﺮﻳﻒ ﻣﺴﺌﻠﻪ ﻭ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎ

 ﭼﺎﻟﺶ ﻫﺎﻱ ﻃﺮﺍﺣﻲ API ﺑﺮﺍﻱ client ﻫﺎﻱ ﻣﺨﺘﻠﻒ (ﻣﺒﺎﻳﻞ، web ﻭ…)

 ﺑﺮﺭﺳﻲ ﺍﺟﻤﺎﻟﻲ API gateway

 ﻣﺰﺍﻳﺎ ﻭ ﻣﻌﺎﻳﺐ ﺍﻳﻦ ﺍﻟﮕﻮ

ﺗﻌﺮﻳﻒ ﻣﺴﺌﻠﻪ ﻭ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎ

ﻣﺎ ﺩﺭ ﻳﻚ ﭘﺮﻭﮊﻩ monolithic ﻓﺮﻭﺷﮕﺎﻫﻲ ﺑﺰﺭﮒ ﻛﺎﺭ ﻣﻲ ﻛﻨﻴﻢ ﻭ ﭘﺲ ﺍﺯ ﻣﺪﺗﻲ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎﻱ ﻛﻪ ﺩﺭ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻳﻜﭙﺎﺭﭼﻪ ﺩﻳﺪﻩ ﻣﻲ ﺷــﻮﺩ ﺗﺼــﻤﻴﻢ ﻣﻲ ﮔﻴﺮﻳﻢ ﻛﻪ ﺑﻪ ﺳــﻤﺖ ﻣﻌﻤﺎﺭﻱ ﻣﻴﻜﺮﻭﺳــﺮﻭﻳﺲ ﺭﻓﺘﻪ ﻭ ﺍﻳﻦ ﺳــﻴﺴــﺘﻢ ﻳﻜﭙﺎﺭﭼﻪ ﺭﺍ ﺑﻪ ﺑﺨﺶ ﻫﺎﻱ ﻣﺴــﺘﻘﻞ ﻭ ﻛﻮﭼﻜﺘﺮﻱ ﺗﻘﺴﻴﻢ ﻧﻤﺎﻳﻢ (ﺩﺭ ﻣﻘﺎﻟﻪ ﻗﺒﻞ ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﺍﺳﺖ)ﻛﻪ ﺍﻳﻦ ﻋﻤﻞ ﺷﺎﻣﻞ ﻣﻌﺎﻳﺐ ﻭ ﻣﺰﺍﻳﺎﻳﻲ ﺧﺎﺹ ﺧﻮﺩ ﻣﻲ ﺑﺎﺷﺪ ﺩﺭ ﻧﻬﺎﻳﺖ trade off ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻛﻪ ﺑﺎﻳﺪ ﺩﺭ ﻣﻮﺭﺩ ﺁﻥ ﺗﺼــﻤﻴﻢ ﮔﺮﻓﺖ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻳﻬﺎﻱ ﻣﺴــﺌﻠﻪ ﺩﺭ ﺍﻳﻦ ﭘﺮﻭﮊﻩ ﺗﺼــﻤﻴﻢ ﺑﻪ ﻛﺎﺭﺑﺮﺩﻥ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﮔﺮﻓﺘﻪ ﻣﻲ ﺷﻮﺩ ﻭ ﺍﺯ ﺁﻧﺠﺎﻳﻲ ﻛﻪ ﺍﻳﻦ ﭘﺮﻭﮊﻩ ﺩﺍﺭﺍﻱ client ﻫﺎ ﻣﺨﺘﻠﻔﻲ ﻣﻲ ﺑﺎﺷﺪﺍﺯ ﺟﻤﻠﻪ:

 ﻣﺒﺎﻳﻞ ( android-ios )

web applications 

 ﺳﺮﻭﻳﺲ ﻫﺎﻱ ﻛﻪ ﺑﺮﺍﻱ ﺍﺳﺘﻔﺎﺩﻩ ( third-party ) ﺳﺎﺯﻣﺎﻥ ﻫﺎ ،ﺩﻳﮕﺮ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻴﺎﻥ ﺍﺭﺍﺋﻪ ﻣﻲ ﮔﺮﺩﺩ.

 …

ﭘﺲ ﻣﺎ ﺩﺍﺭﺍﻱ ﻃﻴﻒ ﻣﺘﻔﺎﻭﺗﻲ ﺍﺯ ﻛﻼﻳﻨﺖ ﻫﺎ ﺧﻮﺍﻫﻴﻢ ﺑﻮﺩ ﻫﻤﻪ ﭼﻴﺰ ﺑﻪ ﻧﻈﺮ ﻋﺎﻟﻲ ﺍﺳﺖ ﺗﺎ ﺑﺎ ﻣﺸﻜﻼﺗﻲ ﺭﻭﺑﺮﻭ ﺧﻮﺍﻫﻴﻢ ﺷﺪ ﻛﻪ ﻣﺎ ﻭ ﭘﺮﻭﮊﻩ ﺭﺍ ﺑﻪ ﭼﺎﻟﺶ ﺧﻮﺍﻫﺪ ﻛﺸﻴﺪ ﺑﻪ ﺑﺮﺭﺳﻲ ﻣﺸﻜﻼﺕ ﻣﻲ ﭘﺮﺩﺍﺯﻳﻢ.

ﻣﺸﻜﻞ ﺍﻭﻝ

ﻓﺮﺽ ﻛﻨﻴﺪ ﺩﺭ ﺳــﻴﺴــﺘﻢ ﻣﻮﻧﻮﻟﻮﺗﻴﻚ ﻛﻼﻳﻨﺖ ﻫﺎ ﺑﺎ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳــﺮﻭﻳﺲ getOrderDetails ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻓﺎﻛﺘﻮﺭ ﻣﺸﺘﺮﻱ،ﻧﻤﺎﻳﺶ ﻓﺎﻛﺘﻮﺭﻫﺎﻱ ﭘﻴﺸﻴﻦ ﻣﺸﺘﺮﻱ،ﻧﻤﺎﻳﺶ ﻛﺎﻻﻫﺎﻱ ﻣﻮﺭﺩ ﻋﻼﻗﻪ ﻣﺸﺘﺮﻱ ﺭﺍ ﺍﺯ ﻃﺮﻳﻖ ﻓﺮﺍﺧﻮﻧﻲ ﺍﻳﻦ ﺳﺮﻭﻳﺲ ﺩﺭﻳﺎﻓﺖ ﻣﻲ ﻛﻨﻨﺪ ﺑﻪ ﺩﻟﻴﻞ ﻳﻜﭙﺎﺭﭼﻪ ﺑﻮﺩﻥ ﺳﻴﺴﺘﻢ ﻭ ﻣﺘﻤﺮﻛﺰ ﺑﻮﺩﻥ ﺩﺍﺩﻫﺎ ﺑﻪ ﺭﺍﺣﺘﻲ ﺍﻣﺎﻥ ﭘﺬﻳﺮ ﺑﻮﺩ ﺍﻣﺎ ﺑﻌﺪ ﺍﺯ ﺍﻳﻨﻜﻪ ﺑﻪ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﻣﻬﺎﺟﺮﺕ ﻣﻲ ﻛﻨﻴﻢ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻳﻜﭙﺎﺭﭼﻪ ﻭ ﻣﺘﻤﺮﻛﺰ ﺑﻪ ﺑﺨﺶ ﻫﺎﻱ ﻛﻮﭼﻜﺘﺮﻱ ﻭ ﻣﺴﺘﻘﻠﻲ ﺗﻘﺴﻴﻢ ﺷﺪﻩ ﺍﺳﺖ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺳﺮﻭﻳﺲ getOrderDetails ﻫﺮ ﺑﺨﺶ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﻛﻪ ﻧﻴﺎﺯ ﺩﺍﺭﺩ ﺩﺭ ﻳﻚ ﻣﻴﻜﺮﻭﺳـﺮﻭﻳﺲ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺍﺳﺖ ﻭ ﻛﻼﻳﻨﺖ ﻫﺎ ﺑﺮﺍﻱ ﮔﺮﻓﺘﻦ ﺍﻃﻼﻋﺎﺕ ﻣﺸـﺘﺮﻱ ﻣﺠﺒﻮﺭ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﺍﺯ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻣﺸﺘﺮﻳﺎﻥ ﻭ ﺑﺮﺍﻱ ﮔﺮﻓﺘﻦ ﺍﻃﻼﻋﺎﺕ ﻛﺎﻻ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻛﺎﻻﻫﺎ ﻭ غیره ﻣﻲ ﺑﺎﺷﺪ .ﺩﺭ ﺭﻭﺵ ﻗﺒﻠﻲ ﻣﺎ ﺑﺎ ﻳﻚ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻳﻚ ﺳــﺮﻭﻳﺲ ﻫﻤﻪ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﺩﺭﻳﺎﻓﺖ ﻣﻴﻜﺮﺩﻳﻢ ﺍﻣﺎ ﺍﻛﻨﻮﻥ ﺑﺎﻳﺪ ﺑﻪ ﺍﻋﻀــﺎﻱ ﻫﺮ ﺑﺨﺶ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﻳﻚ ﺳــﺮﻭﻳﺲ ﺍﺯ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﻣﺘﻔﺎﻭﺕ ﺭﺍ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻛﻨﻴﻢ ﺣﺎﻝ ﺍﮔﺮﺍﺯ ﻃﺮﻳﻖ ﺑ ﺴﺘﺮ ﺍﻳﻨﺘﺮﻧﺖ ﺍﻗﺪﺍﻡ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎ ﻧﻤﺎﻳﻴﻢ ﺩﺭﮔﻴﺮ ﻫﺰﻳﻨﻪ ﻫﺎ ﻭ ﭼﺎﻟﺶ ﻫﺎﻱ ﺍﺯ ﻗﺒﻴﻞ ﭘﻬﻨﺎﻱ ﺑﺎﻧﺪ ﭘﺎﻳﻴﻦ ، ﺗﺄﺧﻴﺮ ﺍﻳﻨﺘﺮﻧﺖ ﻳﺎ ﺷــﺒﻜﻪ ﺗﻠﻔﻦ ﻫﻤﺮﺍﻩ ﻭ…ﺧﻮﺍﻫﻴﻢ ﺑﻮﺩ ﻭ ﺍﮔﺮ ﻛﻨﺪﻱ ﺷــﺒﻜﻪ ﺑﺎﻋﺚ ﺍﻓﺰﺍﻳﺶ response time ﺑﺸــﻮﺩ ﻣﺠﺒﻮﺭ ﺑﻪ ﻗﺒﻮﻝ ﺍﻳﻦ ﺯﻣﺎﻥ ﺩﺭ ﻫﺮ ﺑﺎﺭ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳــﺮﻭﻳﺲ ﻫﺎ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺍﺯ ﻣﻴﻜﺮﻭﺳــﺮﻭﻳﺲ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺧﻮﺍﻫﻴﻢ ﺑﻮﺩ ﺑﺮﺍﻱ ﻛﺎﺭﺑﺮﺍﻥ ﻛﻼﻳﻨﺖ ﻫﺎ ﺁﺯﺍﺭ ﺩﻫﻨﺪﻩ ﻭ ﺗﺠﺮﺑﻪ ﺧﻮﺑﻲ ﺍﺯ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﻴﺴﺘﻢ ﺷﻤﺎ ﻧﺨﻮﺍﻫﻨﺪ ﺩﺍﺷﺖ .

ﻣﺸﻜﻞ ﺩﻭﻡ

ﻣﺸﻜﻠﻲ ﺩﻳﮕﺮ ﭘﻴﺶ ﺭﻭﻱ ﺷﻤﺎ ﻗﺮﺍﺭﺩﺍﺭﺩ ﻭﺍﺑﺴﺘﮕﻲ ﺑﻪ ﻭﺟﻮﺩ ﺁﻣﺪﻩ ﻛﻼﻳﻨﺖ ﻫﺎﻱ ﺷﻤﺎ ﺑﻪ ﺳﺮﻭﻳﺲ ﻫﺎ ﻣﻲ ﺑﺎﺷﺪ ﻭ ﺍﮔﺮ ﺳﺮﻭﻳﺲ ﺑﻪ ﻫﺮ ﺩﻟﻴﻞ ﺗﻐﻴﻴﺮ ﻧﻤﺎﻳﻴﺪ ﻛﻼﻳﻨﺖ ﺩﭼﺎﺭ ﻣﺸﻜﻞ ﺧﻮﺍﻫﻨﺪ ﺷﺪ ﻭ ﺩﺭ ﺑﻌﻀﻲ ﺍﺯ ﻛﻼﻳﻨﺖ ﻋﻤﻠﻴﺎﺕ ﻧﺴﺨﻪ ﮔﺬﺍﺭﻱ ﻛﺎﺭﻱ ﺑﺴﻴﺎﺭ ﺩﺷﻮﺍﺭﻱ ﻣﻲ ﺑﺎﺷﺪ ﻣﺜﻼ ﻣﺒﺎﻳﻞ ﻓﺮﺽ ﻛﻨﻴﺪ ﻛﻪ ﻛﻼﻳﻨﺘﻲ ﺑﺼﻮﺭﺕ ﻣﺴﺘﻘﻴﻢ ﺳﺮﻭﻳﺴﻲ ﺍﺯ ﻳﻚ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﺭﺍ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻣﻲ ﻛﻨﺪ ﺑﻌﺪﻫﺎ ﺗﺼﻤﻴﻢ ﮔﺮﻓﺘﻪ ﻣﻲ ﺷﻮﺩ ﻛﻪ ﺁﻥ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻧﻴﺰ ﺷﻜﺴﺘﻪ ﺷﻮﺩ ﻭ ﺑﻪ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﻫﺎﻱ ﻛﻮﭼﻜﺘﺮ ﺗﺒﺪﻳﻞ ﻣﻲ ﺷﻮﺩ ﺣﺎﻻ ﺩﺍﺩﻩ ﺍﻱ ﻛﻪ ﻧﻴﺎﺯ ﺩﺍﺭﻳﺪ ﺩﺭ ﻳﻚ ﻣﻴﻜﺮﻭﺳــﺮﻭﻳﺲ ﻗﺮﺍﺭ ﻧﺪﺍﺭﺩ ﻭ ﻛﻼﻳﻨﺖ ﻣﺠﺒﻮﺭ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﭼﻨﺪ ﺳــﺮﻭﻳﺲ ﺍﺯ ﻣﺎﻛﺮﻭﺳــﺮﻭﻳﺲ ﻣﺘﻔﺎﻭﺕ ﻣﻲ ﺑﺎﺷــﺪ ﺑﺮﺍﻱ ﺑﺪﺳــﺖ ﺁﻭﺭﺩﻥ ﺍﻃﻼﻋﺎﺕ . ﺁﻳﺎ ﺍﻳﻦ ﻭﺍﺑﺴــﺘﮕﻲ ﻣﺸــﻜﻞ ﺳــﺎﺯ ﻧﺨﻮﺍﻫﺪ ﺑﻮﺩ ﻭ ﻛﻼﻳﻨﺖ ﻫﺎ ﺑﻪ ﻣﺸــﻜﻞ ﺟﺪﻱ ﻧﺨﻮﺍﻫﻨﺪ ﺧﻮﺭﺩ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺑﺎﻳﺪ ﺑﻪ ﺩﻧﺒﺎﻝ ﻗﻄﻊ ﺍﻳﻦ ﻭﺍﺑﺴﺘﮕﻲ ﺑﺎﺷﻴﻢ.

ﻣﺸﻜﻞ ﺳﻮﻡ

ﻣﻤﻜﻦ ﺍﺳﺖ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻫﺎ ﻣﻜﺎﻧﻴﺰﻣﻲ ﺑﺮﺍﻱ ﺍﺭﺗﺒﺎﻁ ﺍﻧﺘﺨﺎﺏ ﻛﺮﺩﻩ ﺑﺎﺷﻨﺪ ﻛﻪ ﺑﺮﺍﻱ ﻓﺮﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎ ﺗﻮﺳﻂ ﻛﻼﻳﻨﺖ ﺑﺴﻴﺎﺭ ﺳـﺨﺖ ﻭ ﭘﻴﭽﻴﺪﻩ ﻛﻨﻨﺪ.ﻳﻌﻨﻲ ﺍﻳﻨﻜﻪ ﻛﻼﻳﻨﺖ ﺑﺮﺍﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳـﺮﻭﻳﺲ ﻣﺠﺒﻮﺭ ﺑﻪ ﭘﻴﺎﺩﻩ ﺳـﺎﺯﻱ ﻛﺪﻫﺎﻱ ﭘﻴﭽﻴﺪﻩ ﻭ ﺳـﺨﺖ ﺧﻮﺍﻫﺪ ﺷـﺪ ﺑﻪ ﺩﻟﻴﻞ ﺍﻧﺘﺨﺎﺏ ﺳــﺮﻭﻳﺲ ﻫﺎ ﺍﺯ ﺗﻜﻨﻮﻟﻮﮊﻱ ﭘﻴﭽﻴﺪﻩ ، ﺑﻨﺎﺑﺮﺍﻳﻦ ﺷــﺎﻳﺪ ﻧﻴﺎﺯ ﺑﻪ ﺩﺭﮔﻴﺮ ﻛﺮﺩﻥ ﻛﻼﻳﻨﺖ ﻫﺎ ﺑﺎ ﺗﻜﻨﻮﻟﻮﺯﻱ ﻫﺎﻱ ﭘﻴﭽﻴﺪﻩ ﻧﺒﺎﺷــﺪ ﻭ ﻛﻼﻳﻨﺖ ﻫﺎ ﺑﺎﻳﺪ ﺩﺭ ﻛﺎﻣﻞ ﺳــﺎﺩﮔﻲ ﺍﺯ ﺳــﺮﻭﻳﺲ ﻫﺎ ﺍﺳــﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻨﺪ ﺩﺭ ﻳﻜﻲ ﺍﺯ ﺗﺠﺮﺑﻪ ﻫﺎﻱ ﻛﺎﺭﻱ ﺧﻮﺩﻡ ﺩﺭ ﺧﺪﻣﺖ ﺩﻭﺳــﺘﺎﻥ ﺑﺰﺭﮒ ﺩﺭ ﻛﺎﺳﭙﻴﻦ ﺗﺼﻤﻴﻢ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﻛﻪ ﻛﻼﻳﻨﺖ ﻫﺎ ﺷﻌﺒﻪ ﺩﺭ ﭘﺮﻭﮊﻩ ﺑﺎﻧﻜﻲ ﺑﺼﻮﺭﺕ ﻣﺴﺘﻘﻴﻢ ﺑﺎ queue ﻛﺎﺭ ﻧﻜﻨﺪ ﻭ ﻻﺯﻡ ﺑﻪ ﺩﺭﮔﻴﺮﻱ ﭘﻴﭽﻴﺪﮔﻲ ﻣﺮﺑﻮﻁ ﺑﻪ ﺻﻒ ﻧﺸﻮﻧﺪ ﻭ ﺭﺍﻩ ﺣﻞ ﻣﻬﻨﺪﺳﻲ ﺟﺎﻟﺒﻲ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﻛﺮﺩﻩ ﺍﻧﺪ .

ﻣﺸﻜﻞ ﭼﻬﺎﺭﻡ

ﻣﺴﺌﻠﻪ ﺍﻱ ﺩﻳﮕﺮﻱ ﻛﻪ ﻣﻄﺮﺡ ﻣﻲ ﺷﻮﺩ ﺍﻳﻦ ﺍﺳﺖ ﺁﻳﺎ ﺗﻤﺎﻡ ﺍﻳﻦ client ﻫﺎ ﻧﻴﺎﺯﻣﻨﺪ ﺑﻪ ﻳﻚ ﻧﻮﻉ ﻃﺮﺍﺣﻲ API ﻫﺴﺘﻨﺪ ﻭ ﺩﺭ ﻧﺘﻴﺠﻪ ﺑﺎﻳﺪ ﺑﻪ ﻳﻚ ﺷـﻜﻞ ﺑﻪ ﺁﻧﻬﺎ ﺳـﺮﻭﻳﺲ ﺩﺍﺩ.ﺑﺪﻳﻦ ﻣﻌﻨﻲ ﻛﻪ ﺳـﺮﻭﻳﺲ ﻫﺎﻱ ﻛﻪ ﺑﻪ ﻛﻼﻳﻨﺖ ﻣﺒﺎﻳﻞ ﺧﻮﺍﻫﻴﻢ ﺩﺍﺩ ﺩﻗﻴﻘﺎ ﺷـﺒﻴﻪ ﺑﻪ ﺳـﺮﻭﻳﺲ ﻫﺎﻱ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻛﻪ ﺑﻪ ﻳﻚ 3rd-party ﺧﻮﺍﻫﻴﻢ ﺩﺍﺩ .ﻗﻄﻌﺎ ﻧﻪ.ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﻛﻪ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎﻱ ﺍﻳﻦ ﺩﻭ ﻛﻼﻳﻨﺖ ﻭ ﺳﻴﺎﺳﺖ ﮔﺬﺍﺭﻱ ﻛﻪ ﻣﺸﺨﺺ ﻛﻨﻨﺪﻩ ﻃﺮﺍﺣﻲ ﻣﻲ ﺑﺎﺷـﺪ ﻛﺎﻣﻼ ﺑﺎ ﻳﻜﺪﻳﮕﺮ ﻣﺘﻔﺎﻭﺕ ﺍﺳ ـﺖ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺑﻪ ﺷ ـﻜﻞ ﻣﺘﻔﺎﻭﺗﻲ ﺳ ـﻌﻲ ﺩﺭ ﺣﻞ ﻣﺴ ـﻠﻪ ﻣﻲ ﻧﻤﺎﻳﻴﻢ ﻣﺜﻞ ﺍﻳﻨﻜﻪ ﻣﺎ ﻫﻤﻪ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﺑﻪ ﻛﻼﻳﻨﺖ ﻫﺎ ﺧﻮﺍﻫﻴﻢ ﺩﺍﺩ client ﻫﺎ ﺗ ﺼﻤﻴﻢ ﺑﮕﻴﺮﻧﺪ ﻛﻪ ﻧﻴﺎﺯ ﺑﻪ ﻧﻤﺎﻳﺶ ﭼﻪ ﺍﻃﻼﻋﺎﺗﻲ ﺍ ﺳﺖ ﺧﻮﺏ ﻣ ﺸﻜﻞ ﺍ ﺳﺎ ﺳﻲ ﻣﻲ ﺗﻮﺍﻧﺪ ﺩﺭ ﺍﻳﻦ ﺷﻜﻞ ﺑﺤﺚ ﻫﺎﻱ ﺍﻣﻨﻴﺖ ﺑﺎ ﺷﺪ ﻭ ﻳﺎ ﺩﺭ ﻫﺮ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﻃﺮﺍﺣﻲ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺩﺍ ﺷﺘﻪ ﺑﺎ ﺷﻴﻢ ﺑﺮﺍﻱ ﻫﺮ ﻛﻼﻳﻨﺖ ﺩﺭ ﺻﻮﺭﺗﻲ ﺍﮔﺮ ﻧﻴﺎﺯ ﺑﻪ ﺗﻐﻴﻴﺮﻱ ﺑﺎﺷﺪ ﻣﺠﺒﻮﺭ ﺑﻪ ﺗﻐﻴﻴﺮ ﺳﺮﺍﺳﺮ ﺳﺮﻭﻳﺲ ﻫﺎ ﺩﺭ ﻫﻤﻪ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻫﺎ ﺧﻮﺍﻫﻴﻢ ﺑﻮﺩ.

ﺍﻟﮕﻮﻱ API Gateway

ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﻣﺴﺎﺋﻞ ﭘﻴﺶ ﺁﻣﺪﻩ ﺭﺍ ﻣﺸﺎﻫﺪﻩ ﻧﻤﻮﺩﻳﺪ ﺍﻳﻦ ﺍﻟﮕﻮ ﺑﺎ ﺍﺿﺎﻓﻪ ﻛﺮﺩﻥ ﻳﻚ ﻻﻳﻪ ﻗﺒﻞ ﺍﺯ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎ ﻭ ﺑﻌﺪ ﺍﺯﻓﺎﻳﺮﻭﺍﻝ ﻳﻌﻨﻲ ﺩﺭ zone ﺷﺮﻛﺖ ﻗﺮﺍﺭ ﺩﺍﺭﻳﻢ ﺩﻗﻴﻘﺎ ﺑﻴﻦ ﻓﺎﻳﺮﻭﺍﻝ ﻭ ﻣﺎﻛﺮﻭﺳﺮﻭﻳﺲ ﻫﺎ ﺍﻗﺪﺍﻡ ﺑﻪ ﺣﻞ ﻣﺸﻜﻞ ﻣﻲ ﻧﻤﺎﻳﻴﺪ ﺍﻳﻦ ﻻﻳﻪ ﺑﻪ ﻋﻨﻮﺍﻥ ﺩﺭﮔﺎﻩ ﻭﺭﻭﺩﻱ ﺳــﺮﻭﻳﺲ ﻫﺎ ﺑﻪ ﻛﺎﺭ ﻣﻲ ﺭﻭﺩ ﺑﺪﻳﻦ ﻣﻌﻨﻲ ﻛﻪ ﻛﻼﻳﻨﺖ ﻫﺎ ﺑﻪ ﺟﺎﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻣﺴــﺘﻘﻴﻢ ﺳــﺮﻭﻳﺲ ﻫﺎ ﺑﺎﻳﺪ ﺍﺯ ﻻﻳﻪ API Gateway ﺍﻗﺪﺍﻡ ﻧﻤﺎﻳﻴﻨﺪ ﺍﮔﺮ ﺑﺨﻮﺍﻫﻴﻢ ﻧﮕﺎﻩ OOP ﺑﻪ ﻣﺴـﺌﻠﻪ ﺩﺍﺷـﺘﻪ ﺑﺎﺷـﻴﻢ ﭼﻴﺰﻱ ﺷـﺒﻴﻪ ﺑﻪ ﺍﻟﮕﻮﻱ ﻃﺮﺍﺣﻲ Facade ﻣﻲ ﺑﺎﺷـﺪ ﻛﻪ ﺑﺎ ﺍﺿﺎﻓﻪ ﻛﺮﺩﻥ ﻳﻚ ﻻﻳﻪ ﺳﻄﺢ ﺑﺎﻻ ﺑﺮﺍﻱ ﺳﺎﺩﻩ ﻛﺮﺩﻥ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻻﻳﻪ ﻫﺎﻱ ﭘﺎﻳﻴﻨﺘﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﺷﻮﺩ ﺑﺎ ﺍﺿﺎﻓﻪ ﺷﺪﻥ ﺍﻳﻦ ﻻﻳﻪ ﺑﺎ ﻧﺎﻡ API Gateway ﻣ ﺴﺎﺋﻞ ﻭ ﻣ ﺸﻜﻼﺕ ﻣﻄﺮﺡ ﺷﺪﻩ ﺭﺍ ﺑﺮ ﻃﺮﻑ ﺧﻮﺍﻫﻴﻢ ﻛﺮﺩ ﺑﻪ ﺗ ﺼﻮﻳﺮ ﺯﻳﺮ ﺩﻗﺖ ﻧﻤﺎﻳﻴﺪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﺗﻮ ﺿﻴﺤﺎﺕ ﺍﻳﻨﻜﻪ ﭼﮕﻮﻧﻪ ﺍﻳﻦ ﺍﻟﮕﻮ ﻣﺸﻜﻼﺕ ﺭﺍ ﺣﻞ ﺧﻮﺍﻫﺪ ﻛﺮﺩ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ.


ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﻣﺸﺎﻫﺪﻩ ﻣﻲ ﻧﻤﺎﻳﻴﺪ ﺑﻪ ﺟﺎﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻣﺴﺘﻘﻴﻢ ﺳﺮﻭﻳﺲ ﻫﺎ ﺗﻮﺳﻂ ﻛﻼﻳﻨﺖ ﻫﺎ ﺍﻳﻨﺒﺎﺭ ﻛﻼﻳﻨﺖ ﻫﺎ ﺍﺯ ﻃﺮﻳﻖ API Gateway ﺍﻗﺪﺍﻡ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳــﺮﻭﻳﺲ ﻫﺎ ﺧﻮﺍﻫﻨﺪ ﻧﻤﻮﺩ ﭼﻮﻥ ﻣﺎﮊﻭﻝ API Gateway ﺩﺭ ﻫﻤﺎﻥ LAN ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﻛﻪ ﺑﺎﻗﻲ ﻣﻴﻜﺮﻭﺳــﺮﻭﻳﺲ ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﺑﻨﺎﺑﺮﺍﻳﻦ ﻫﺰﻳﻨﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳـﺮﻭﻳﺲ ﻫﺎ ﺑﺴـﻴﺎﺭ ﺣﺪﺍﻗﻞ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﻣﻄﺮﺡ ﺷـﺪ ﺑﻪ ﺩﻟﻴﻞ ﻣﻴﻜﺮﻭﺳـﺮﻭﻳﺲ ﺷـﺪﻥ ﻳﻜﻲ ﺍﺯ ﻣﺸﻜﻼﺕ ﻣﺎ ﺷﻜﺴﺘﻦ ﻳﻚ ﺳﺮﻭﻳﺲ ﺑﺰﺭﮒ ﺑﻪ ﺳﺮﻭﻳﺲ ﻫﺎﻱ ﻛﻮﭼﻜﺘﺮ ﺩﺭ ﺑﻴﻦ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻫﺎﻱ ﺩﻳﮕﺮ ﺍﺳﺖ ﺑﺎ ﻭﺟﻮﺩ ﺍﻳﻦ ﻻﻳﻪ ﻣﺎ ﻣﻲ ﺗﻮﺍﻧﻴﻢ ﻳﻚ ﺳـﺮﻭﻳﺲ ﺩﺭ API Gateway ﺑﻨﻮﻳﺴـﻢ ﻛﻪ ﻣﺎﻧﻨﺪ ﻳﻚ ﺳـﺮﻭﻳﺲ ﺑﺰﺭﮒ ﻫﻤﻪ ﺍﻃﻼﻋﺎﺕ ﻻﺯﻡ ﺭﺍ ﺍﺯ ﻣﻴﻜﺮﻭﺳـﺮﻭﻳﺲ ﻫﺎﻱ ﻻﺯﻡ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻣﻲ ﻛﻨﺪ ﻭ ﺑﻪ ﺩﻟﻴﻞ ﺍﻳﻨﻜﻪ ﻻﻳﻪ API Gateway ﺑﻪ ﺻﻮﺭﺕ ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻫﺎ ﺩﺳﺘﺮﺳﻲ ﺩﺍﺭﺩ ﻭ ﻭﻇﻴﻘﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﺭﺍ ﺭﺍ ﺑﺮﻋﻬﺪﻩ ﺩﺍﺭﺩ ﺍﺯ ﺁﻧﭽﻪ ﻛﻪ ﻫﻤﻪ ﺍﻳﻦ ﺍﺗﻔﺎﻕ ﻫﺎ ﺩﺭ ﻳﻚ LAN ﺭﺥ ﻣﻲ ﺩﻫﺪ ﻫﺰﻳﻨﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎ ﺍﺯ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﻫﺎ ﺑﺴﻴﺎﺭ ﻧﺎﭼﻴﺰ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﺩﺭ ﻧﺘﻴﺠﻪ ﻛﺎﺭﺑﺮ ﺍﺣﺴﺎﺱ ﺑﻬﺘﺮﻱ ﺍﺯ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﻴﺴﺘﻢ ﺷﻤﺎ ﺧﻮﺍﻫﺪ ﺩﺍﺷﺖ ﻭ ﻧﻴﺎﺯ ﺑﻪ ﺍﻧﺘﻈﺎﺭ ﮔﺬﺍﺷﺘﻦ ﻛﺎﺭﺑﺮ ﻧﺨﻮﺍﻫﺪ ﺑﻮﺩ.

ﻭﻇﺎﻳﻒ API Gateway :

1.ﻣﺴﻴﺮ ﺩﻫﻲ ( Route ) ﺑﻪ ﺭﻳﻜﻮﺳﺘﻬﺎ

ﺩﺭ ﺍﻳﻦ ﺍﻟﮕﻮ ﭼﻮﻥ request ﻫﺎ ﻣ ﺴﺘﻘﻴﻤﺎ ﺑﻪ ﺩ ﺳﺖ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﻫﺎ ﻧﻤﻲ ﺭ ﺳﻨﺪ ﻭ ﺍﺯ ﺍﻳﻦ ﻻﻳﻪ ﻋﺒﻮﺭ ﻣﻲ ﻛﻨﺪ ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﻭ ﺍﻳﻦ ﻗﺎﺑﻠﻴﺖ ﺍﻣﻜﺎﻥ ﺗﺼﻤﻴﻢ ﮔﻴﺮﻱ ﻛﻪ ﺍﻳﻦ ﺩﺭﺧﻮﺍﺳﺖ ﺑﻪ ﺩﺳﺖ ﻛﺪﺍﻡ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﺑﺮﺍﻱ ﭘﺮﺩﺍﺯﺵ ﺑﺮﺳﺪ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﺩﺭ ﺍﻳﻦ ﻗﺴﻤﺖ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﻛﻠﻲ ﺳﻴﺎﺳﺘﻬﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﺪ ﻛﻪ request ﺗﻮﺳﻂ ﭼﻪ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﭘﺮﺩﺍﺯﺵ ﺷﻮﺩ ﻭﺑﻨﺎﺑﺮﺍﻳﻦ ﺑﺎ ﺑﻪ ﻭﺟﻮﺩ ﺁﻭﺭﺩﻥ ﻳﻚ ﮔﻠﻮﮔﺎﻩ ﺑﺮﺍﻱ ﻋﺒﻮﺭ ﻭ ﻣﺮﻭﺭ ﺍﻣﻜﺎﻥ ﺍﻋﻤﺎﻝ ﺳﻴﺎ ﺳﺖ ﻣﺘﻨﻮﻉ ﺍﻣﻜﺎﻥ ﭘﺬﻳﺮ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻣﺜﻞ ﺍﻳﻨﻜﻪ ﭼﻪ request ﺭﺍ ﭼﻪ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﭘﺮﺩﺍﺯﺵ ﻛﻨﺪ ﻭ ﻳﺎ ﺍﻳﻦ ﺩﺭﺧﻮﺍﺳﺖ ﺑﻪ ﻛﺠﺎ Route ﺷﻮﺩ ﺍﻣﻜﺎﻥ ﭘﺬﻳﺮ ﺍﺳﺖ .

2.ﺗﺮﻛﻴﺐ ﺳﺮﻭﻳﺲ ﻫﺎ

ﻧﻜﺘﻪ ﺩﻳﮕﺮ ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﻣﻄﺮﺡ ﺷـﺪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳـﺮﻭﻳﺲ ﻫﺎ ﺑﺼـﻮﺭﺕ ﺯﻳﺎﺩ ﺑﺎ ﺗﻮﺟﻪ ﺑﺮ ﺑﺴـﺘﺮ ﺍﻳﻨﺘﺮﻧﺖ ﺑﺎﻋﺚ ﺑﺮﻭﺯ ﻣﺸـﻜﻼﺗﻲ ﺧﻮﺍﻫﺪ ﻭ ﺩﺭ ﻧﻬﺎﻳﺖ ﺗﺎﺛﻴﺮ ﺟﺬﺍﺑﻲ ﺑﺮ ﺭﻭﻱ ﻛﺎﺭﺑﺮ ﻧﺨﻮﺍﻫﺪ ﺩﺍﺷـــﺖ . ﺑﻴﺎﻳﺪ ﻓﺮﺽ ﻛﻨﻴﺪ ﻛﻪ ﺻــﻔﺤﻪ ﺍﻭﻝ client ﻣﺎ ﻗﺼـــﺪ ﺩﺍﺭﻳﻢ ﺍﻃﻼﻋﺎﺗﻲ ﺍﺯ ﻗﺒﻴﻞ order,Delivery,Bill,Ticket ﺭﺍ ﺩﺭ ﺻﻔﺤﻪ ﺍﻭﻝ ﻧﻤﺎﻳﺶ ﺑﺪﻡ ﺩﺭ ﺣﺎﻟﺖ ﻗﺒﻞ ﻛﻼﻳﻨﺖ ﻫﺎ ﻣﺠﺒﻮﺭ ﺑﻮﺩﻥ ﺑﻪ ﺍﺯﺍﻱ ﻫﺮ ﺑﺨﺶ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﻳﻚ ﺳــﺮﻭﻳﺲ ﺭﺍ ﺻــﺪﺍ ﺑﺰﻧﻨﺪ ﺍﻣﺎ ﺩﺭ ﺭﻭﺵ API gateway ﺑﺎ ﻳﻜﺒﺎﺭ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺩﺭ ﺍﻳﻦ ﻻﻳﻪ ﺗﻤﺎﻡ ﺍﻃﻼﻋﺎﺕ ﺍﺯ ﻣﻴﻜﺮﻭﺳــﺮﻭﻳﺲ ﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻛﺮﺩﻩ ﻭ ﭼﻮﻥ ﺗﻤﺎﻡ ﺍﻳﻦ ﺍﺗﻔﺎﻕ ﺩﺭ LAN ﺳﺎﺯﻣﺎﻥ ﺍﺗﻔﺎﻕ ﻣﻲ ﺍﻓﺘﺪ ﻫﺰﻳﻨﻪ ﺑﺴﻴﺎﺭ ﻛﻤﺘﺮﻱ ﻧﺴﺒﺖ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺍﺯ ﻃﺮﻳﻖ ﺍﻳﻨﺘﺮﻧﺖ ﺩﺍﺭﺩ ﻭ ﺩﺭ ﻳﻜﺒﺎﺭ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺗﻤﺎﻡ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﻪ client ﺩﺍﺩﻩ ﻣﻲ ﺷﻮﺩ .

3.ﺳﺎﺩﻩ ﺳﺎﺯﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎ

ﻣﻴﻜﺮﻭﺳــﺮﻭﻳﺲ ﻫﺎﻱ ﻣﺎ ﻣﻤﻜﻦ ﺍﺳـــﺖ ﺍﺯ ﺗﻜﻨﻮﻟﻮﮊﻱ ﭘﻴﭽﻴﺪﻱ ﺑﺮﺍﻱ expose ﺳــﺮﻭﻳﺲ ﻫﺎ ﺍﺳــﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻴﺪ ﻭ ﺍﻳﻦ ﺑﺮﺍﻱ ﻛﻼﻳﻨﺖ ﻫﺎﻱ ﭘﻴﭽﻴﺪﻳﮕﻲ ﺑﺮﺍﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎ ﺑﻪ ﻭﺟﻮﺩ ﺑﻴﺎﻭﺭﺩ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ API gateway ﻣﺎ ﻣﻲ ﺗﻮﺍﻧﻴﻢ ﺳﺮﻭﻳﺲ ﻫﺎﻱ ﻻﺯﻡ ﺗﻮﺳﻂ gateway ﺑﺼﻮﺭﺕ restful ﻭ ﻳﺎ ﭘﺮﻭﺗﻮﻛﻞ ﻫﺎﻱ ﺳﺎﺩﻩ ﺗﺮﻱ ﺩﺭ ﺍﺧﺘﻴﺎﺭ client ﻗﺮﺍﺭ ﺩﻫﻴﻢ ﺣﺎﻻ ﻛﻼﻳﻨﺖ ﻫﺎ ﺳﺎﺩﻩ ﺗﺮ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﺍﺯ ﺳﺮﻭﻳﺲ ﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻨﺪ.

4.ﻃﺮﺍﺣﻲ ﺍﺧﺘﺼﺎﺻﻲ API ﺑﺮﺍﻱ ﻫﺮ ﻛﻼﻳﻨﺖ

ﻧﻜﺘﻪ ﺍﻱ ﺩﻳﮕﺮ ﻛﻪ ﻧﻴﺎﺯ ﺑﻪ ﺍﺷﺎﺭﻩ ﺩﺍﺭﺩ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﻫﺮ ﻛﻼﻳﻨﺖ ﻣﻤﻜﻦ ﺍﺳﺖ ﻧﻴﺎﺯ ﻣﻨﺪﻱ ﻫﺎﻱ ﻃﺮﺍﺣﻲ API ﺧﻮﺩ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻣﺜﻼ ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﺮﺍﻱ ﺳﺮﻭﻳﺲ Get Order Details ﺑﺮﺍﻱ ﻛﻼﻳﻨﺖ ﻳﻚ ﻧﻮﻉ ﻃﺮﺍﺣﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻢ ﺍﻣﺎ ﺑﺮﺍﻱ 3rd party ﻣﺎ ﻳﻪ ﻃﺮﺍﺣﻲ ﻣﺘﻔﺎﻭﺗﻲ ﺍﻧﺘﻈﺎﺭ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻢ ﺑﺎ ﻭﺟﻮﺩ ﺍﻳﻦ ﺍﻟﮕﻮ ﻣﻲ ﺗﻮﺍﻧﻴﻢ ﺗﺼﻤﻴﻢ ﺑﮕﻴﺮﻡ ﻛﻪ ﺑﺮﺍﻱ ﻫﺮ ﻛﻼﻳﻨﺖ ﺑﺎ ﭼﻪ ﻃﺮﺍﺣﻲ ﻭ ﺳﻴﺎﺳﺘﻲ API ﺩﺭ ﺍﺧﺘﻴﺎﺭ ﺁﻧﺎﻥ ﻗﺮﺍﺭ ﺩﻫﻴﻢ ﺑﺪﻭﻥ ﺍﻳﻨﻜﻪ ﻛﺪ ﺍﺻــﻠﻲ ﺭﺍ ﺑﺎ ﺍﻳﻦ ﻧﻴﺎﺯ ﻛﺜﻴﻒ ﻛﻨﻴﻢ ﺩﺭ ﺍﻳﻦ ﺭﻭﺵ ﻻﻳﻪ API Gateway ﻭﻇﻴﻘﻪ ﺍﻳﻨﻜﻪ ﻫﺮ API ﺭﺍ ﺑﺎ ﻃﺮﺍﺣﻲ ﺑﻪ ﻫﺮ ﻛﻼﻳﻨﺖ ﺍﺧﺘﺼﺎﺹ ﺩﻫﻴﻢ ﺭﺍ ﺩﺍﺭﺍﺳﺖ.

5.ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻋﻤﻠﻴﺎﺕ ﻟﺒﻪ ﺍﻱ

ﻣﻨﻈﻮﺭ ﺍﺯ ﻋﻤﻠﻴﺎﺕ ﻟﺒﻪ ﺍﻱ ﻋﻤﻠﻴﺎﺗﻲ ﻣﻲ ﺑﺎ ﺷﺪ ﻛﻪ ﻣﺎ ﻗﺼﺪ ﺩﺍﺭﻳﻢ ﺯﻣﺎﻥ ﻛﻪ request ﻭﺍﺭﺩ ﺳﻴﺴﺘﻢ ﻣﻲ ﺷﻮﺩ ﺑﺮ ﺭﻭﻱ ﺁﻥ ﺍﻋﻤﺎﻝ ﺷﻮﺩ ﻣﺎﻧﻨﺪ ﺍﻳﻨﻜﻪ ﺍﺯ ﻧﻈﺮ ﺍﻋﺘﺒﺎﺭ ﺳﻨﺠﻲ ﺍﻳﻦ request ﺑﺮﺭﺳﻲ ﺷﻮﺩ ﻭ ﺩﺭ ﺻﻮﺭﺗﻲ ﻛﻪ ﻣﻌﺘﺒﺮ ﻧﺒﺎﺷﺪ ﺍﺩﺍﻣﻪ ﻧﺨﻮﺍﻫﻴﻢ ﺩﺍﺩ ﻭ ﻫﻤﭽﻨﻴﻦ ﻋﻤﻠﻴﺎﺗﻲ ﻣﺎﻧﻨﺪ :

Authentication 

Authorization 

Rate limiting 

Caching 

Metrics collection 

Request logging 

ﺑﻨﺎﺑﺮﺍﻳﻦ ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﻣﺸــﺎﻫﺪﻩ ﻣﻲ ﻧﻤﺎﻳﻴﺪ ﺷــﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﻳﻚ API Gateway ﭘﻴﭽﻴﺪﺗﺮﻱ ﺍﺯ ﻭﺿــﻴﻔﻪ ﺍﺻــﻠﻲ ﺍﻟﮕﻮ API routing ﻭ composition ﻡ ﺍﻧﺠﺎﻡ ﺑﺪﻫﺪ ﺍﻟﺒﺘﻪ ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻳﻦ ﻣﻮﺍﺭﺩ ﻣﻲ ﺗﻮﺍﻧﺪ ﺑﺮﺍﻱ ﻫﺮ ﻛﻼﻳﻨﺖ ﻛﺎﻣﻼ ﻣﺘﻔﺎﻭﺕ ﺑﺎﺷــﺪ ﻭ ﺑﻪ ﺟﺎﻱ ﺍﻳﻨﻜﻪ ﺍﻳﻦ ﻣﻮﺍﺭﺩ ﺑﻪ ﺳﺮﻭﻳﺲ ﻫﺎ ﺑﺮ ﺳﺪ ﻣﻲ ﺗﻮﺍﻧﻴﻢ ﺩﺭ ﺍﻳﻦ ﻻﻳﻪ ﻣﺘﻤﺮﻛﺰ ﻛﻨﻴﻢ ﻭ ﺍﺟﺎﺯﻩ ﺩﻫﻴﻢ ﺍﻳﻦ ﭘﻴﭽﻴﺪﮔﻲ ﺩﺭ ﺍﻳﻦ ﻻﻳﻪ ﻫﺎ ﺍﺗﻔﺎﻕ ﺑﻴﻔﺘﺪ ﻭ ﻫﺮ client ﻳﻚ API Gateway ﻣﺮﺑﻮﻁ ﺑﻪ ﺧﻮﺩ ﺑﺎ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﺧﻮﺩ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﺍﻟﺒﺘﻪ ﻫﺮ ﻛﺪﺍﺭﻡ ﺍﺯ ﺍﻳﻦ ﻣﻮﺍﺭﺩ ﻣﻄﺮﺡ ﺷﺪﻩ ﻧﻴﺰ ﻧﻴﺎﺯ ﺑﻪ ﺗﻮﺿﻴﺢ ﻣﻲ ﺑﺎﺷﺪ ﻛﻪ ﺩﺭ ﻣﻘﺎﻟﻪ ﻫﺎﻱ ﺑﻌﺪﻱ ﻣﻮﺭﺩ ﺑﺮﺭﺳﻲ ﻗﺮﺍﺭ ﺧﻮﺍﻫﺪ ﮔﺮﻓﺖ.

ﻣﺰﺍﻳﺎ ﻭ ﻣﻌﺎﻳﺐ ﺍﻳﻦ ﺍﻟﮕﻮ

ﻣﺰﺍﻳﺎ ﺑﻪ ﻣﻔﺼﻞ ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﺍﻣﺎ ﺩﻭ ﻭﻇﻴﻔﻪ ﺍﺻﻠﻲ ﻳﻌﻨﻲ routing ﻭ composition ﺑﺎﺭ ﺩﻳﮕﺮ ﺍﺷﺎﺭﻩ ﻣﻲ ﺷﻮﺩ :

 ﻛﭙﺴﻮﻟﻪ ﺷﺪﻥ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻫﺎ ﺑﻪ ﺩﻟﻴﻞ ﺍﻳﻨﻜﻪ ﺳﺮﻭﻳﺲ ﻫﺎ ﺑﺮﺍﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎ ﺑﺎﻳﺪ ﻳﻚ ﺳﺮﻭﻳﺲ ﺍﺯ ﻻﻳﻪ

API Gateway ﺭﺍﺧﻮﺍﻧﻲ ﻛﻨﺪ ﺑﻬﻢ ﺩﻟﻴﻞ ﻛﻼﻳﻨﻬﺎ ﻭﺍﺑﺴﺘﮕﻲ ﺑﻪ ﺳﺮﻭﻳﺲ ﻫﺎ ﻧﺪﺍﺭﻧﺪ.

 ﻣﺰﺍﻳﺎﻳﻲ ﺩﻳﮕﺮ ﺑﺪﻭﻥ ﺍﺳــﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﺍﻟﮕﻮ ﻛﻼﻳﻨﺖ ﻫﺎ ﻣﺠﺒﻮﺭ ﺑﻮﺩﻥ ﺑﺮﺍﻱ ﺑﺮﻃﺮﻑ ﻛﺮﺩﻥ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎﻱ ﺧﻮﺩ ﺳــﺮﻭﻳﺲ ﻫﺎﻱ

ﻛﻮﭼﻚ ﻭ ﺯﻳﺎﺩﻱ ﺭﺍ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻛﻨﻨﺪ ﺍﻣﺎ ﺩﺭ ﺍﻳﻦ ﺭﻭﺵ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﺪ ﺑﺎ ﺩﺍ ﺷﺘﻦ ﻳﻚ ﺳﺮﻭﻳﺲ ﺩﺭ API Gateway ﻛﻪ ﺧﻮﺩ ﺍﻳﻦ

ﺳــﺮﻭﻳﺲ ﻭﻇﻴ ﻔﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳــﺮﻭﻳﺲ ﻫﺎﻱ ﻻﺯﻡ ﺭﺍ ﺑﺮﻋ ﻬﺪﻩ ﺩﺍﺭﺩ ﻭ ﺍﺯ ﺁﻧ ﺠﺎ ﻛﻪ ﺩﺭ ﻳﻚ ﻣﺎﮊﻭﻝ API Gateway ﺑﺎ ﺑﺎﻗﻲ

ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻫﺎ ﺩﺭ ﻳﻚ LAN ﻣﻴﺒﺎﺷﻨﺪ ﻫﺰﻳﻨﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﺩﺭ ﺍﻳﻦ ﻣﺎﮊﻭﻝ ﺑﺴﻴﺎﺭ ﭘﺎﻳﻴﻦ ﺗﺮ ﺍﺯ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺍﻳﻦ ﺳﺮﻭﻳﺲ

ﻫﺎ ﺍﺯ ﻛﻼﻳﻨﺖ ﻫﺎ ﺑﺮ ﺑﺴﺘﺮ ﺍﻳﻨﺘﺮﻧﺖ ﺭﺍ ﺧﻮﺍﻫﺪ ﺩﺍﺷﺖ.

ﻣﻌﺎﻳﺐ

 ﺑﻪ ﻭﺟﻮﺩ ﺁﻣﺪﻥ ﻣﺎﮊﻭﻟﻲ ﺟﺪﻳﺪ ﻛﻪ ﻧﻴﺎﺯ ﺗﻮﺳﻌﻪ،ﺍﺳﺘﻘﺮﺍﺭ،ﻣﺪﻳﺮﻳﺖ ﺩﺍﺭﺩ.

API Gateway ﻳﻚ ﻧﻘﻄﻌﻪ ﺧﻄﺮ ﻧﺎﻙ ﺩﺭ ﺳـﻴﺴـﺘﻢ ﺑﻪ ﻭﺟﻮﺩ ﻣﻲ ﺁﻭﺭﺩ ﻛﻪ ﻣﻲ ﺗﻮﺍﻧﺪ ﻛﻞ ﺳـﻴﺴـﺘﻢ ﺭﺍ fail ﻛﻨﺪ ﭼﻮﻥ ﺍﮔﺮ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺑﻪ ﻫﺮ ﺩﻟﻴﻞ ﺩﭼﺎﺭ ﺧﻄﺎ ﺑﺸﻮﺩ ﻛﻞ ﺳﻴﺴﺘﻢ ﺑﻪ ﺧﻄﺎ ﺧﻮﺍﻫﺪ ﺧﻮﺭﺩ.

 ﺍﮔﺮ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺭﺍ ﻣﻘﺎﻳﺲ ﭘﺬﻳﺮ ﻃﺮﺍﺣﻲ ﻧﻜﻨﻴﻢ ﻣﻤﻜﻦ ﺍﺳﺖ ﺗﺒﺪﻳﻞ ﺑﻪ bottleneck ﺩﺭ ﺳﻴﺴﺘﻢ ﺑﺸﻮﺩ.

 ﺍﮔﺮ ﻳﻚ ﺗﻴﻢ ﻭﻇﻴﻔﻪ ﻧﻮﺷـﺘﻦ API Gateway ﺭﺍ ﺩﺍﺷـﺘﻪ ﺑﺎﺷـﻪ ﻣﺎ ﺩﭼﺎﺭ ﻳﻚ ﻭﺍﺑﺴـﺘﮕﻲ ﺑﻪ ﺍﻳﻦ ﺗﻴﻢ ﺧﻮﺍﻫﻴﻢ ﺷـﺪ.ﺍﻟﺒﺘﻪ ﻗﺎﺑﻞ ﺑﺤﺚ ﺍﺳﺖ.
 ﺑﻪ ﻫﺮ ﺣﺎﻝ ﻣﺎ ﻳﻚ ﻻﻳﻪ ﺍﺿﺎﻓﻪ ﺑﻪ ﻭﺟﻮﺩ ﺁﻭﺭﺩﻩ ﺍﻳﻢ ﻛﻪ ﺍﻳﻦ ﻻﻳﻪ ﺧﻮﺩ ﻧﻴﺎﺯ ﺑﺎﻋﺚ ﺑﻪ ﻭﺟﻮﺩ ﺁﻭﺭﺩﻥ ﻛﻨﺪﻱ ﺧﻮﺍﻫﺪ ﺷﺪ ﻛﻪ ﺍﻟﺒﺘﻪ ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺑﺎ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎﻱ ﻛﻮﭼﻚ ﺗﻮﺳﻂ ﻛﻼﻳﻨﺖ ﻫﺎ ﺑﺮ ﺑﺴﺘﺮ ﺍﻳﻨﺘﺮﻧﺖ ﺑﺎﺯ ﻫﻢ ﻗﺎﺑﻞ ﺗﻮﺟﻴﺢ ﻣﻲ ﺑﺎﺷﺪ.

ﭘﺎﻳﺎﻥ

ﺩﻭﺳﺘﺎﻥ ﺧﻮﺑﻢ ﺍﻣﻴﺪﻭﺍﺭﻡ ﻟﺬﺕ ﺑﺮﺩﻩ ﺑﺎﺷﻴﻦ ﻭ ﺧﻮﺷﺤﺎﻟﻢ ﻣﻴﺸﻢ ﻛﻪ ﺩﺭ ﺍﻳﻦ ﻣﻮﺭﺩ ﺑﺎ ﻫﻢ ﺩﺍﻧﺸﻤﻮﻥ ﺭﻭ ﺑﻪ ﺍﺷﺘﺮﺍﻙ ﺑﮕﺬﺍﺭﻳﺪ.

https://Github.com/LotfiAli

LotfiAliDev@gmail.com

: ﻣﻨﺒﻊ

Microservices Patterns WITH EXAMPLES IN JAVA C HRIS R ICHARDSON

https://docs.microsoft.com/

دسته بندی شده در:

برچسب ها:

,