پلتفرم میان‌پایه تأیید اطلاعات مکانی برای مدیریت منابع طبیعی در پاسخ به مسائلی مانند توسعه مکرر، مقیاس‌پذیری کم و قوانین تأیید ناسازگار در سیستم‌های کاربردی تأیید و نظارت موجود طراحی شده است. ابتدا معماری پلتفرم میانی و میکرو سرویس ها را مورد بحث قرار دادیم و الزامات کسب و کار را نیز بررسی کردیم. در مرحله دوم، ما معماری پلت فرم تأیید اطلاعات مکانی را ارائه کردیم. در نهایت روش کاربرد در کسب و کار تایید زمین ساختمانی معرفی شده است. کاربردهای عملی ثابت کردند که پلت فرم تأیید اطلاعات مکانی بسیار مقیاس پذیر و قابل نگهداری است، با اجزای تجاری قابل استفاده مجدد و خدمات داده برای انواع سیستم های کاربردی امور دولتی.
کلید واژه ها:
منابع طبیعی ؛ امور دولتی ؛ تایید اطلاعات مکانی ; پلت فرم میانی کسب و کار ; پلت فرم میانی داده ; میکرو سرویس
1. مقدمه
بخش منابع طبیعی چین کنترل یکپارچه استفاده از زمین و فضا را در چین به عهده می گیرد. به منظور انجام مؤثر این مسئولیت‌ها و ارتقای توانایی‌های حکمرانی، ساخت رسمی «One Map» را راه‌اندازی کرد که به یک پایگاه داده ملی یکپارچه اشاره می‌کند که حاوی اطلاعات تمام منابع طبیعی، چه در بالا یا زیر زمین، روی زمین یا در دریا [ 1]. با پشتیبانی از مفهوم مدیریت مبتنی بر داده، عملکرد تأیید اطلاعات مکانی باید بیشتر و بیشتر در فرآیند تأیید و نظارت بر امور استفاده از زمین و فضا اصلاح شود. این به طور پویا مختصات فضایی موضوعات مدیریت امور دولتی را با محدوده کنترل فضایی “یک نقشه” منابع طبیعی مقایسه می کند و هدف از مقایسه و تحلیل آنلاین بلادرنگ ارائه پایگاه داده به موقع برای تصمیم گیری مدیریت امور دولتی و به موقع است. شناسایی و رهگیری موقعیت هایی که الزامات کنترل زمین و فضا را در فرآیند تأیید برآورده نمی کنند. به منظور حمایت از الزامات مدیریتی تأیید اطلاعات فضایی برای کنترل استفاده از زمین و فضا، سیستم‌های مدیریت دولتی مختلف به‌طور متوالی ساخته شده‌اند و به توابع تأیید اطلاعات فضای آنلاین مجهز شده‌اند. از آنجا که هر سیستم به طور مستقل توسعه یافته است، بیشتر توابع تأیید اطلاعات مکانی آنها به عنوان یک ماژول عملکردی کل سیستم امور دولتی وجود دارد. بنابراین آنها با سایر ماژول های عملکردی در سیستم همراه هستند و توسط سیستم های خارجی غیرقابل دسترسی هستند. به دلیل توسعه مستقل آنها، تضمین اینکه قوانین تأیید اطلاعات مکانی کاملاً سازگار هستند نیز چالش برانگیز است. این سیستم ها همچنین مقیاس پذیری و کارایی توسعه ضعیفی دارند و امکان گسترش عملکرد تأیید اطلاعات جغرافیایی را در صورت لزوم غیرممکن می کند. علاوه بر این، رشد همزمانی بسیار محدود است. با افزایش تعداد درخواست های کاربر، پاسخ تا حد زیادی به تأخیر خواهد افتاد، زیرا گره های پردازش جدید را نمی توان به راحتی به ماژول اضافه کرد. همه این مسائل باید مورد توجه قرار گیرد تا نیازهای نظارتی رو به رشد و سختگیرانه برآورده شود.
از نظر معماری سیستم، ساختار مونومر کلاسیک با کوپلینگ کد بالا دارای چندین اشکال مختلف از جمله مقیاس پذیری کم و هزینه های نگهداری بالا است که آن را برای ساختن پلت فرم های سیستم پیچیده نامناسب می کند. معماری سرویس گرا (SOA) این مسائل را حل می کند. معماری SOA سرویس را به عنوان مرکز قرار می دهد و از ESB (Enterprise Service Bus) برای پیاده سازی فراخوانی رابط بین سرویس ها استفاده می کند [ 2 ]. انعطاف پذیری و مقیاس پذیری سیستم را تا حد زیادی بهبود می بخشد. SOA به دلیل ساختار عظیم گذرگاه خدمات ESB برای برنامه های کاربردی در سطح سازمانی مناسب تر است. به عنوان یک پلت فرم خدمات داده در سطح سازمانی در مقیاس بزرگ. فناوری میکرو سرویس در سال‌های اخیر به سرعت پیشرفت کرده است و معماری میکرو سرویس، تصعید SOA است [ 3 ]]. سرویس‌های میکرو بر مؤلفه‌سازی و سرویس‌دهی خدمات و عملکردها تأکید می‌کنند و سیستم را به سرویس‌های خرد مجزا تقسیم می‌کنند که ممکن است به طور مستقل توسعه یافته و عملیاتی شوند و در نهایت منجر به معماری سیستمی با انسجام بالا و حداقل اتصال می‌شود. نمونه‌هایی از مزایای سرویس‌های میکرو عبارتند از: ذخیره‌سازی توزیع‌شده، در دسترس بودن بالا، مقیاس‌پذیری و مدیریت هوشمند، نگهداری و غیره. معماری پلتفرم میانی، که بیشتر توسط علی‌بابا ترویج می‌شود، در سال‌های اخیر رایج شده است. علی بابا اولین کسی بود که استراتژی «سکوی متوسط بزرگ، سکوی جلوی کوچک» را پیشنهاد کرد [ 4]، که خدمات مشترک و قابلیت های داده سازمان ها را در هر پلتفرم میانی پالایش و یکپارچه می کند و در نتیجه یک پلت فرم قابل استفاده مجدد ایجاد می کند. مشکلات سیستم توسعه مکرر و راندمان پایین را حل کرد. معماری پلتفرم میانی نشان دهنده روش شناسی حاکمیت سازمانی است، در حالی که معماری خدمات خرد اجرای فناوری است. خدمات میکرو در حال حاضر معمولاً بهترین اجرای معماری پلتفرم میانی در صنعت در نظر گرفته می شوند [ 5 ]. برخی از مطالعات روش ساخت و ساز مبتنی بر خدمات میکرو را برای یک پلت فرم میانی تحلیل کرده اند [ 6 ، 7 ، 8 ، 9 ، 10 ، 11]. استفاده از میکرو سرویس ها نه تنها قابلیت استفاده مجدد، بلکه مقیاس پذیری و نگهداری پلت فرم را نیز بهبود می بخشد.
بر اساس یافته های بالا، این مقاله طراحی یک پلت فرم مدیریت منابع طبیعی و تأیید اطلاعات مکانی را بر اساس معماری میکرو سرویس برای دستیابی به ساخت یک پلت فرم میانی پیشنهاد می کند. این نه تنها نیازهای توسعه سریع عملکرد تأیید هر سیستم برنامه را برآورده می کند، مشکلات توسعه مکرر، تنظیم سریع و گسترش را حل می کند، بلکه با استفاده مجدد از توابع و داده ها، سازگاری قوانین تأیید را تضمین می کند و سرویس تأیید را بیشتر می کند. کارآمد و یکپارچه
2. بررسی اجمالی Micro-Service و Middle Platform
2.1. معماری میکرو سرویس
معماری میکرو سرویس ها روشی برای ایجاد یک اپلیکیشن واحد از یک سری سرویس های کوچک است. میکرو سرویس یک برنامه کاربردی کوچک است که می تواند به طور مستقل اجرا شود، به طور مستقل مقیاس شود و به طور مستقل آزمایش شود و یک مسئولیت واحد دارد. این یک مسئولیت به معنای اصلی است که یک دلیل واحد برای تغییر و/یا یک دلیل واحد برای جایگزینی دارد. با این حال، محور دیگر یک مسئولیت واحد است به این معنا که فقط یک کار و یک کار را به تنهایی انجام می دهد و به راحتی قابل درک است [ 12 ].]. بر اساس یک مکانیسم ارتباطی سبک وزن، سرویس ها برای ایجاد یک برنامه جامع همکاری و هماهنگی می کنند. از نظر ساختار، “اتصال کمی” بین خدمات میکرو وجود دارد. در اصل، میکرو سرویس‌ها هنوز شکلی از معماری SOA هستند، اما مقیاس‌پذیرتر هستند و به نوآوری‌های تکنولوژیکی کمک می‌کنند زیرا به فناوری خاصی وابسته نیستند. معماری سنتی یکپارچه، بر خلاف معماری میکرو سرویس‌ها، همه اجزا را در یک فرآیند واحد ترکیب می‌کند و آنها را در یک سرور واحد ذخیره می‌کند و همه اجزا در یک پایگاه داده به اشتراک می‌گذارند. هنگامی که یک کامپوننت تغییر می کند، تمام اجزای دیگر باید کامپایل، بسته بندی و دوباره نصب شوند. روابط جفت پیچیده بین اجزای خدمات وجود دارد که نگهداری و گسترش آن دشوار است و نوآوری فنی را تشویق نمی کند.
استفاده از توسعه معماری میکروسرویس نیازمند مدیریت‌های خاصی است که اغلب شامل کشف سرویس، پیکربندی سرویس، فیوزینگ، محدود کردن جریان، متعادل‌سازی بار و سایر وظایف می‌شود. برای حل موثر این مشکلات، Dubbo، Spring Cloud، Service Mesh و سایر فریم ورک‌های میکرو سرویس راه‌اندازی شده‌اند. در میان آنها، Spring Cloud یکی از پرکاربردترین فریم ورک ها است. این شامل اجزایی مانند کشف سرویس، تعادل بار، مرکز پیکربندی، قطع کننده مدار، نظارت بر داده ها، گذرگاه پیام و موارد دیگر است که می تواند نیازهای حاکمیت خدمات خرد را برآورده کند [ 13 ].
2.2. معماری پلتفرم میانی
معماری پلتفرم میانی به جای یک سیستم کاربردی که با یک جهت یا کانال تجاری روبرو باشد، خدمات اصلی و توانایی داده شرکت را برای هر پلتفرم افزایش داد. پلتفرم میانی به عنوان یک پلتفرم استفاده مجدد برای قابلیت‌های اصلی عمل می‌کند و در عین حال قسمت جلویی و پشتی را هماهنگ می‌کند و پاسخگویی جلویی و ثبات پشتی را افزایش می‌دهد. معماری پلتفرم میانی شامل پلتفرم های میانی کسب و کار، داده و فناوری است. پلتفرم میانی کسب و کار به پلت فرم خدمات عمومی اشاره دارد که عملکردهای مشترک هر سیستم کاربردی را به یک سرویس یکپارچه تبدیل می کند که می تواند در همان زمان فراخوانی شود. پلتفرم میانی داده به یک پلت فرم خدمات عمومی مرتبط با داده اشاره دارد که تمام داده های داخلی را به داده های استاندارد تبدیل می کند و خدمات کلان داده سازگار و بسیار در دسترس را ارائه می دهد. پلتفرم میانی فناوری به یک پلت فرم خدمات عمومی مبتنی بر فناوری اشاره دارد که بر یکپارچه سازی منابع و بارش ظرفیت تأکید دارد، مانند پلت فرم ابر زیرساخت، پلت فرم ابر کانتینری، پلت فرم چارچوب توسعه میکرو سرویس و غیره.
به طور خاص، تفاوت زیادی بین یک مرکز تجاری و یک مرکز داده وجود دارد. مرکز داده بر یکپارچه سازی استانداردهای داده و جزئیات تأکید دارد و داده ها را در خدمات پایگاه داده، خدمات پرتره برچسب، خدمات مدل سازی الگوریتم و غیره محصور می کند تا هوش تجاری میز جلو را بهبود بخشد. از سوی دیگر، مرکز تجاری بر استفاده مجدد کارآمد از فرآیندها و خدمات تأکید دارد [ 14 ].
2.3. ترکیبی از بستر میانی و میکرو سرویس
ایجاد یک پلتفرم میانی نشان دهنده ایدئولوژی حاکمیت سازمانی است، در حالی که خدمات خرد اجرای معماری فنی است. سرویس‌های میکرو در حال حاضر معمولاً به عنوان بهترین پیاده‌سازی معماری پلتفرم میانی در صنعت شناخته می‌شوند [ 5 ]. فلسفه پلتفرم میانی این است که ماژول های رایج را برای برنامه های کاربردی جلویی قابل استفاده مجدد کند. در حالی که ایدئولوژی خدمات خرد این است که در هنگام توسعه یک ماژول مشترک، جداشدنی، توسعه پذیر و ضعیف به هم متصل شوند. همانطور که در شکل 1 نشان داده شده استبر اساس معماری پلتفرم میانی سرویس‌های میکرو، پلتفرم میانی به واحدهای مؤلفه‌ای تقسیم می‌شود که سپس به میکرو سرویس‌ها تجزیه می‌شوند، سپس تابع برنامه از طریق فراخوانی بین میکرو سرویس‌ها، مؤلفه‌ها و سیستم‌های کاربردی ساخته می‌شود. پلتفرم میانی دارای ویژگی های مولفه سازی و مدولارسازی است و می تواند به سیستم برنامه کاربردی front-end تحویل داده شود تا اجزای مناسب را برای انجام عملیات تجاری فراخوانی کند. با استفاده از میکرو سرویس‌هایی که بر پایه پلتفرم میانی قرار دارند، نه تنها می‌توان مقیاس‌پذیری و قابلیت نگهداری را افزایش داد، بلکه قابلیت‌های پردازش همزمان را نیز می‌توان افزایش داد.
3. وضعیت تجاری و تقاضا
3.1. تقاضاهای کسب و کار
وزارت منابع طبیعی مسئولیت نظارت بر ده‌ها امور دولتی را بر عهده دارد که از نظر زمینه‌های تجاری به مدیریت کاربری اراضی، مدیریت حقوق معدنی و مدیریت استفاده از دریا و از نظر نوع مدیریت به وظایف تصویب و نظارت تقسیم می‌شود. . برای همه انواع امور، فرآیند کار شامل اعلام عمومی، بررسی داخلی و بازرسی میدانی دولت، استعلام اطلاعات عمومی و غیره است. . در حال حاضر، تأیید اطلاعات مکانی توسط سیستم کلان داده منابع طبیعی “One Map” پشتیبانی می شود که با هزاران لایه شامل جغرافیای پایه، تصاویر سنجش از دور، و همچنین سایر داده های منابع طبیعی زمین، زمین شناسی، مواد معدنی، اقیانوس ها، جنگل ها، مراتع و تالاب ها، میزان این داده ها به طور مداوم در حال افزایش و به روز رسانی است. این منجر به نیازهای پیچیده برای تأیید اطلاعات مکانی می شود.
به منظور پرداختن به چنین نیازهای پیچیده الزامات راستی‌آزمایی داده‌های مکانی، پلتفرم میانی راستی‌آزمایی اطلاعات مکانی دارای مزایایی است که می‌تواند توابع راستی‌آزمایی بسیار قابل استفاده مجدد را به سرویس‌های مختلف مدیریت دولتی ارائه دهد و قوانین راستی‌آزمایی بسیار سازگار را حفظ کند.
3.2. خواسته های عملکرد
عملکرد تأیید اطلاعات جغرافیایی کسب و کار مدیریت امور دولتی بسیار پیچیده است و در معرض تغییر است. علاوه بر این، حجم دسترسی تابع تأیید اطلاعات جغرافیایی سال به سال به سرعت در حال افزایش است که در نتیجه گسترش تجارت و حجم داده‌ها، نیاز فوق‌العاده‌ای به توان عملیاتی ایجاد می‌کند. علاوه بر این، نیاز مدیریت اداری به اینکه عملکرد تأیید اطلاعات مکانی به مدت 24 ساعت به صورت آنلاین در دسترس باشد، نگرانی های بیشتری را در مورد پایداری سیستم به همراه دارد. همه این عوامل الزامات عملکرد بالاتری را برای طراحی و توسعه پلت فرم میانی به ارمغان آورده است.
بنابراین، پلت فرم میانی تأیید اطلاعات مکانی باید بتواند به سرعت گسترش یابد و به‌روزرسانی‌ها را تا حد امکان ارزان و سریع انجام دهد. همچنین باید قابلیت اطمینان بالایی داشته باشد و در صورت خرابی نسبت به خود متحمل خطا باشد. به‌علاوه، باید بتواند توان عملیاتی بالایی را در زمینه چندین کاربر مدیریت کند. فریم‌ورک‌های میکرو سرویس گزینه‌ای عالی برای برآورده کردن معیارهای عملکرد فوق‌الذکر هستند زیرا در مقایسه با چارچوب‌های یکپارچه معمولی، دارای حداقل کوپلینگ، راندمان توسعه بالا، مقیاس‌پذیری بالا و تحمل خطا بالا هستند.
4. طراحی پلت فرم تایید اطلاعات مکانی
4.1. طراحی کلی معماری
این بخش معماری یک پلت فرم مدیریت منابع طبیعی و تأیید اطلاعات مکانی را نشان می دهد که بر اساس مفهوم یک پلت فرم متوسط ساخته شده است و با نیازهای تجاری مدیریت منابع طبیعی و تأیید اطلاعات مکانی یکپارچه شده است. همانطور که در شکل 2 نشان داده شده است، معماری پلتفرم میانی به لایه داده، لایه میکروسرویس، لایه پلت فرم میانی داده و کسب و کار و لایه کاربرد سیستم جدا می شود .
پشتیبانی داده برای عملکرد کلی سیستم توسط لایه داده ارائه می شود که حاوی داده های “One Map” و داده های ویژگی تجاری است. لایه ریز سرویس شامل عملکردها در کوچکترین دانه بندی، مانند خدمات داده های مکانی و خدمات تحلیل فضایی، از طریق پلت فرم اطلاعات پایه فضای سرزمینی است، این توابع ادغام شده و برای استفاده بر اساس کاتالوگ منابع یکپارچه در دسترس قرار می گیرند. پلتفرم تجاری میانی ماژول های تابعی را برای ارائه خدمات نقشه کلی و توابع تأیید در بسیاری از خطوط تجاری از طریق فراخوانی متقابل و ترکیب توابع لایه میکرو سرویس ساخته است.
4.2. طراحی پلتفرم میانی کسب و کار
پلتفرم میانی تجاری شامل پلتفرم میانی سرویس نقشه دولتی، پلتفرم میانی تأیید صحت اطلاعات مکانی و سیستم مدیریت پیکربندی تأیید صحت اطلاعات مکانی است.
سیستم خدمات نقشه دولتی توابع نقشه جهانی را برای انواع سیستم های کاربردی تجاری، مانند پیکربندی نقشه، مدیریت لایه، مرور نقشه، پرس و جو نقشه، تجزیه و تحلیل فضایی، تجسم، و نمایش دسته ای پروژه و غیره ارائه می دهد. در جزئیات، پیکربندی نقشه لایه ها را به هم متصل می کند. منابع سرویس داده و نمادهای نقشه را پیکربندی می کند، در حالی که مرور نقشه، نقشه های برداری، نقشه های شطرنجی، نقشه های توپوگرافی سه بعدی، نقشه های تیاندیتو و انواع دیگر عملیات نمایش نقشه را فعال می کند. ماژول پرس و جو نقشه عملکردهایی مانند پرس و جوهای فضایی لایه نقشه عمومی، پرس و جوهای ویژگی لایه، پرس و جوهای لیست تعداد پروژه و موارد دیگر را ارائه می دهد. ماژول تجسم اطلاعات مختصات لات ارائه شده از فرآیند تأیید را در قالب JSON یا WKT برای تکمیل نقشه فضایی تجزیه می کند.
پلتفرم میانی تأیید صحت اطلاعات مکانی یک مؤلفه خدمات تأیید فضایی یکپارچه، مانند ایجاد وظایف تأیید جدید، نظارت بر پیشرفت کار، و ماژول‌های مشاهده نتایج را فراهم می‌کند که توسط هر سیستم برنامه کاربردی امور دولتی قابل دسترسی است. قبل از ایجاد و ارسال یک کار تأیید جدید، کاربران باید شناسه مدل احراز هویت را پاس کنند. ماژول نظارت بر پیشرفت کار برای ردیابی وضعیت تأیید در زمان واقعی استفاده می شود و ماژول مشاهده نتیجه برای مشاهده داده های تأیید و گزارش پس از تکمیل استفاده می شود.
از طریق یک رابط گرافیکی، سیستم مدیریت پیکربندی اطلاعات فضایی عملکردهای مختلفی را ارائه می دهد، از جمله لباس پوشیدن قوانین، لباس پوشیدن مدل، تست مدل، مدیریت وظیفه و نظارت، و بسیاری موارد دیگر. قوانین تأیید فردی را می توان برای دستیابی به سفارشی سازی مدل تأیید تجاری و تسهیل توسعه های پویا سفارشی کرد. سپس ممکن است این مدل در ماژول تست آزمایش شود تا کاربرد آن تأیید شود. وظایف تأیید را می توان برای شناسایی ناهنجاری ها ردیابی و کنترل کرد، و این سیستم شامل یک ماژول برای کمک به کاربران برای مقابله با آنها است. برای انتقال آسان‌تر مدل تأیید، ماژول انتقال مدل از واردات و صادرات قوانین و پیکربندی‌ها پشتیبانی می‌کند.
سرویس‌های میکرو برای پیاده‌سازی توابع تخصصی پلتفرم میانی کسب‌وکار استفاده می‌شوند، که از طریق دروازه API با یکدیگر فراخوانی و هماهنگ می‌شوند تا توابع خدمات پلتفرم میانی تجاری را ایجاد کنند. فریم ورک میکرو سرویس Spring Cloud برای ایجاد مدیریت یکپارچه و حاکمیت دقیق میکرو سرویس ها و همچنین عملکردهایی مانند قطع کننده مدار سرویس و محدود کردن جریان سرویس استفاده می شود که پایداری سیستم را تضمین می کند.
4.3. طراحی پایگاه داده میانی
پایگاه داده میانی فقط بستر اطلاعاتی پایه فضای سرزمینی است. این پلتفرم تجاری میانی را با داده های نقشه و توابع تحلیل فضایی تامین می کند.
بستر اطلاعاتی پایه فضای سرزمینی دارای یک معماری کاربردی و خدماتی توزیع شده است. بر اساس ثبت، انتشار، زمان‌بندی، و خدمات نظارتی ارائه شده توسط گذرگاه خدمات SOA در سطح سازمانی، امکان یکپارچه‌سازی توزیع‌شده داده‌ها و خدمات فیزیکی پراکنده را فراهم می‌کند. این پلتفرم داده های منابع طبیعی مانند جغرافیای پایه، زمین، منابع معدنی، زمین شناسی، اقیانوس، جنگل، مرتع و تالاب را بر اساس وضعیت فعلی و برنامه ریزی آینده طبقه بندی می کند. این به ایجاد یک «نقشه واحد» از داده‌های منابع طبیعی و نیازهای خدمات کمک کرد. از طریق دسترسی به سرویس، اشتراک‌گذاری داده‌ها و بایگانی بلادرنگ، داده‌ها از گره‌های راه دور به بستر اطلاعات پایه فضای سرزمینی برای مدیریت یکپارچه و خدمات کاربردی متصل می‌شوند.
همانطور که در شکل 3 نشان داده شده است ، کلان داده های منابع طبیعی از طریق یک زیرساخت فنی توزیع شده مدیریت می شوند. مبادله داده ها، به اشتراک گذاری داده ها، و تجمیع خدمات همه در مرکز ملی انجام می شود. از نظر فناوری، مرکز اصلی ملی از یک پایگاه داده توزیع شده و یک چارچوب محاسباتی موازی توزیع شده برای دستیابی به ذخیره سازی و محاسبات ابری استفاده می کند تا خدمات ابری را با دسترسی به داده ها و محاسبات فعال کند. سرویس‌های ابری از پروتکل‌های HTTP، وب سرویس و OGC برای ساخت سرویس‌های میکرو (RESTful API)، سرویس‌های مرسوم و سرویس‌های OGC برای ارائه خدمات اطلاعاتی به مشتریان داخلی و خارجی استفاده می‌کنند.
5. کاربردهای عملی
بر اساس چارچوب فوق، تابع تایید هوشمند برای اطلاعات مکانی سرویس تایید زمین ساخت و ساز طراحی و توسعه یافته است. در ساختار مونومر کلاسیک، هر سیستم خدمات مجموعه ای از توابع تأیید و معیارهای تأیید سرویس را ایجاد و حفظ می کند. منابع موجود، به این ترتیب، قابل استفاده مجدد نیستند، و بهره وری توسعه بسیار پایین است، که تحقق خواسته های تغییر سریع در مدیریت کسب و کار را غیرممکن می کند. عملکرد تأیید هوشمند اطلاعات مکانی کسب و کار تأیید زمین ساخت و ساز با استفاده از معماری شرح داده شده در بالا ایجاد می شود، و این یک نمونه کاربردی خاص از پلت فرم مدیریت منابع طبیعی و تأیید اطلاعات مکانی در عمل است.
5.1. مدل تجاری
الزامات تأیید صحت اطلاعات مکانی کسب و کار تأیید زمین ساختمانی به شرح زیر است:
-
بررسی نوع همپوشانی کاربری. طبقه بندی زمین پایه با استفاده از داده های “سومین بررسی منابع زمین ملی” در سال 2020 تأیید می شود که شامل تأیید قانونی زمین ساخت و ساز، تجزیه و تحلیل گذشته نگر زمین شناسی زمین ساخت و ساز بدون منابع قانونی، و تجزیه و تحلیل طبقه بندی برای وضعیت سال قبل (2019) است. سایر اراضی کشاورزی علاوه بر تأیید طبقه بندی زمین، تراز زمین زراعی در زمین زراعی فعلی بررسی می شود و تعادل دینامیکی زمین های زراعی در سایر زمین های کشاورزی از سال قبل به عنوان زمین زراعی بررسی می شود.
-
راستی آزمایی خط قرمز برنامه ریزی فضای سرزمینی. این شامل راستی‌آزمایی زمین‌های کشاورزی پایه دائمی و خط قرمز اکولوژیکی پوشش است. مدل کسب و کار راستی‌آزمایی اطلاعات مکانی، همانطور که در شکل 4 نشان داده شده است، برای علامت‌گذاری تجزیه و تحلیل داده‌هایی که باید انجام شود و داده‌های مورد استفاده مطابق با الزامات کسب‌وکار تأیید اطلاعات مکانی تأیید زمین ساخت‌وساز طراحی شده است. سپس ایجاد تابع تأیید بر اساس مدل کسب و کار تأیید است.
5.2. فرآیند توسعه پلتفرم میانی
از پلت فرم میانی برای طراحی تابع تأیید اطلاعات مکانی تأیید زمین ساخت و ساز بر اساس مدل تجاری تأیید اطلاعات مکانی استفاده کنید. همانطور که در شکل 5 نشان داده شده است ، کاربرد فرآیند توسعه پلتفرم میانی به شش مرحله تقسیم می‌شود: مدل‌سازی کسب‌وکار، جمع‌آوری داده‌ها، توسعه خدمات، ثبت خدمات، پیکربندی مدل، و کاربرد پلتفرم میانی.
مرحله مدل‌سازی کسب‌وکار الزامات تأیید کسب‌وکار را با جزئیات تجزیه و تحلیل می‌کند، از جمله اینکه کدام سرویس‌های داده باید استفاده شوند و کدام‌ها باید ایجاد شوند، در حالی که مدل‌های کسب‌وکار را نیز می‌سازد (همانطور که در شکل 4 نشان داده شده است ).
داده های گمشده در پلتفرم میانی با توجه به نیازهای سرویس در مرحله جمع آوری داده ها جمع آوری می شود.
توسعه داده ها و خدمات تجزیه و تحلیل داده ها بخشی از مرحله توسعه خدمات داده است. توسعه خدمات تجزیه و تحلیل داده ها از یک سو به منظور توسعه خدمات تحلیل تک لایه و از سوی دیگر توسعه خدمات تحلیل موضوعی چند لایه بنا به نیاز است. مثال دیگر تجزیه و تحلیل پیش از زمین شناسی عطف به ماسبق زمین ساخت و ساز بدون منابع قانونی است که شامل تجزیه و تحلیل چند لایه داده های بررسی کاربری زمین از سال 2009 تا 2018 است.
مرحله ثبت خدمات، خدمات داده و خدمات تحلیل داده را در بستر اطلاعاتی پایه فضای سرزمینی ثبت می کند. در مرحله پیکربندی مدل کسب و کار، از طریق سیستم مدیریت پیکربندی تأیید صحت، پلتفرم میانی کسب و کار هر قانون تأیید و مدل تأیید کسب و کار را پیکربندی می کند. قانون تأیید یک پروژه خدمات تجزیه و تحلیل داده های فردی است، مانند تجزیه و تحلیل همپوشانی با داده های وضعیت کاربری زمین در سال 2020. نمودار غیر چرخشی جهت دار (DAG) برای سازماندهی مجموعه ای از قوانین تأیید در مدل تأیید کسب و کار استفاده می شود. پیکربندی در سکوی میانی نقشه شامل منبع سرویس داده نقشه، نماد نمایش نقشه و ترتیب نمایش لایه نقشه است.
در مرحله درخواست پلت فرم میانی، رابط توسعه جلویی سیستم تأیید زمین ساخت و ساز، ماژول های مربوطه پلت فرم میانی تجاری را برای اجرای عملکرد تأیید، مانند ارسال وظایف و به دست آوردن وضعیت و نتایج، فراخوانی می کند. نتایج تأیید ادغام متن و تصویر با استفاده از پلت فرم میانی نقشه پیاده سازی می شود.
5.3. نتایج برنامه Middle Platform
مثال‌های بالا نشان می‌دهند که چگونه اپلیکیشن پلتفرم میانی ممکن است به سرعت به نیازها و تغییرات کسب‌وکار راستی‌آزمایی امور دولتی پاسخ دهد. در عین حال، هدف پلت فرم میانی دستیابی به قابلیت های تجاری در سطح سازمانی و استفاده مجدد از داده ها است. توابع و داده های کسب و کار که به طور منظم در سناریوهای مختلف تجاری ساخته می شوند، در بستر کسب و کار و داده میانی سپرده می شوند. بر اساس سناریوهای کاربردی معمولی ذکر شده در بالا، عملکرد تأیید، سرویس داده، سرویس تجزیه و تحلیل داده، مدل تنظیم تأیید صحت، تأیید مدل کسب و کار و پیکربندی نقشه ایجاد می شود که می تواند توسط سایر مشاغل با پر کردن داده های فردی مجدداً استفاده شود. تنظیمات پیکربندی ساده، کارایی توسعه را تا حد زیادی بهبود بخشیده است. همزمان،
با در نظر گرفتن کاربرد تابع راستی‌آزمایی اطلاعات مکانی در کاربری زمین ساخت‌وساز، ما معماری میکرو سرویس را با معماری یکپارچه مرسوم مقایسه کردیم. شکل 6 تغییرات در طراحی سیستم را مقایسه می کند.
همانطور که در شکل 6 الف نشان داده شده است، در معماری کلاسیک یکپارچه، تابع تأیید اطلاعات مکانی به عنوان یک ماژول از سیستم اعلام یک مرحله ای کار می کند، که به شدت با ماژول های دیگر همراه است و برای سیستم تجاری بیرونی غیرقابل دسترسی است. برعکس، همانطور که در شکل 6 ب مشاهده می شود، در سیستم مبتنی بر پلت فرم میانی و سرویس های میکرو، یک پلت فرم مستقل را تشکیل می دهد و از سایر ماژول ها در سیستم اعلامیه جدا می شود. با فراخوانی مؤلفه‌های سرویس پلت فرم میانی، هر دو سیستم تجاری داخلی و خارجی می‌توانند به عملکرد تأیید اطلاعات مکانی دسترسی داشته باشند.
جدول 1 تأخیر، قابلیت استفاده مجدد، قابلیت اطمینان، مقیاس پذیری، توان عملیاتی و هزینه توسعه را مقایسه می کند.
6. نتیجه گیری
این مقاله یک پلت فرم تأیید اطلاعات جغرافیایی را برای امور دولتی منابع طبیعی طراحی و پیاده‌سازی می‌کند که شامل پلتفرم میانی تجاری و بستر میانی داده است. پلتفرم میانی تجاری که بر اساس معماری فناوری مبتنی بر خدمات میکرو ساخته شده است، با موفقیت یک مکانیسم تأیید اطلاعات مکانی هوشمند بسیار قابل استفاده مجدد را ایجاد می کند، که پشتیبانی قوی برای برنامه های کاربردی در امور مختلف دولتی منابع طبیعی فراهم می کند. از توسعه تکراری جلوگیری می کند، مشکل قوانین تأیید ناسازگار ناشی از سیستم های ساختاری یکپارچه کلاسیک را حل می کند و مقیاس پذیری و ظرفیت پردازش موازی را ارتقا می دهد. با تکیه بر بستر اطلاعات پایه فضای سرزمینی، پلتفرم میانی داده مجموعه‌ای از خدمات داده‌های مکانی مدیریت‌شده توزیع‌شده و سرویس‌های تجزیه و تحلیل داده‌های مکانی را ارائه می‌کند، پشتیبانی قوی از داده‌ها را برای پلتفرم میانی کسب‌وکار فراهم می‌کند و مشکلات محاسباتی کلان داده را حل می‌کند. همچنین، ویژگی‌های پلتفرم میانی کسب‌وکار و پلتفرم میانی داده کاملاً متمایز هستند، پلتفرم میانی داده بر یکپارچه‌سازی استانداردها و کالیبر داده‌ها تأکید می‌کند و داده‌ها را در خدماتی مانند خدمات پایگاه داده، خدمات پرتره برچسب، خدمات مدل الگوریتم کپسوله می‌کند. و غیره، برای حمایت از کسب و کار میز جلو هوشمند تر. پلتفرم میانی کسب و کار بر استفاده مجدد کارآمد از فرآیند و خدمات تأکید دارد. این باعث می‌شود که معماری کلی مقیاس‌پذیرتر، قابل نگهداری و نوآوری‌های تکنولوژیکی باشد. بیش از ده مورد تأیید دولت منابع طبیعی با موفقیت و پیوسته توسط پلتفرم میانی تأیید اطلاعات جغرافیایی پشتیبانی شده است. استفاده از پلتفرم میانی وضعیت توسعه مستقل هر خط تجاری را در داخل سیستم معماری یکپارچه اصلی ساده می کند، که باعث افزایش اثربخشی توسعه، کاهش هزینه های توسعه و دستیابی به قوانین یکسان تأیید اطلاعات مکانی می شود. بر خلاف طراحی یکپارچه، معماری میکرو سرویس استفاده شده بهبود قابل توجهی در عملکرد از نظر قابلیت اطمینان، مقیاس پذیری، توان عملیاتی و غیره ارائه می دهد. استفاده از پلتفرم میانی وضعیت توسعه مستقل هر خط تجاری را در داخل سیستم معماری یکپارچه اصلی ساده می کند، که باعث افزایش اثربخشی توسعه، کاهش هزینه های توسعه و دستیابی به قوانین یکسان تأیید اطلاعات مکانی می شود. بر خلاف طراحی یکپارچه، معماری میکرو سرویس استفاده شده بهبود قابل توجهی در عملکرد از نظر قابلیت اطمینان، مقیاس پذیری، توان عملیاتی و غیره ارائه می دهد. استفاده از پلتفرم میانی وضعیت توسعه مستقل هر خط تجاری را در داخل سیستم معماری یکپارچه اصلی ساده می کند، که باعث افزایش اثربخشی توسعه، کاهش هزینه های توسعه و دستیابی به قوانین یکسان تأیید اطلاعات مکانی می شود. بر خلاف طراحی یکپارچه، معماری میکرو سرویس استفاده شده بهبود قابل توجهی در عملکرد از نظر قابلیت اطمینان، مقیاس پذیری، توان عملیاتی و غیره ارائه می دهد.
این مقاله طراحی و اجرای پلتفرم میانی تأیید اطلاعات مکانی را در زمینه تقاضای واقعی برای مدیریت امور دولتی منابع طبیعی چین مورد بحث قرار داد. ساختار پلتفرم به وضوح بین پلتفرم کسب و کار و پلت فرم داده تمایز قائل می شود و وقتی با استفاده از معماری میکرو سرویس ترکیب می شود، عملکرد و عملکرد هر دو به طور قابل توجهی افزایش یافته است. در نتیجه، این طراحی معماری یک راه حل عملی برای سناریوهای کاربردی شامل تجزیه و تحلیل داده های بزرگ فضایی پیچیده ارائه می دهد.
پلت فرم میانی تأیید اطلاعات فضایی هنوز با چالش هایی روبرو است که باید به آنها توجه کرد و در تحقیقات آینده بهبود بخشید. اولین چالش این است که مرزهای بین پلتفرم میانی و سیستم تجاری جلویی را دقیقاً تعریف کنید. برای افزایش قابلیت استفاده مجدد و اطمینان از مدیریت سازگار، پلت فرم میانی باید با استفاده از توابع مشترک جهانی ایجاد شود. دوم، ممکن است تعیین سطح مناسبی از دانه بندی برای خدمات خرد دشوار باشد. آنها باید بر اساس مدل کسب و کار باشند و به ویژه، هر یک از آنها باید سعی کنند از تراکنش های توزیع شده اجتناب کنند تا از ثبات داده های قوی اطمینان حاصل شود. در نهایت، با افزایش کمیت و پیچیدگی خدمات خرد، نظارت و حاکمیت ممکن است برای افزایش پایداری سیستم ضروری باشد.
منابع
- وزارت منابع طبیعی طرح کلی اطلاع رسانی ساختمان وزارت منابع طبیعی. وب سایت دولت چین در دسترس به صورت آنلاین: https://www.gov.cn/xinwen/2019-11/23/content_5454833.htm (در 23 نوامبر 2019 قابل دسترسی است).
- وو، جی. لیو، جی. Xi, C. مطالعه بر روی معماری سرویس گرا بر اساس وب سرویس. مد. الکترون. تکنولوژی 2005 ، 14 ، 1-4. [ Google Scholar ]
- فنگ، ز. خو، ی. Xue، X. چن، اس. بررسی توسعه معماری میکروسرویس. جی. کامپیوتر. Res. توسعه دهنده 2020 ، 57 ، 1103-1122. [ Google Scholar ] [ CrossRef ]
- ژونگ، اچ. تحول چارچوب فناوری اطلاعات در شرکتها. در تفکر استراتژیک و چارچوب علی بابا ؛ چاپ ماشین چین: پکن، چین، 2017. [ Google Scholar ]
- او، سی. دنگ، دی. معماری و پیاده سازی پلتفرم میانی. در بر اساس DDD و Microservices ; چاپ ماشین چین: پکن، چین، 2020. [ Google Scholar ]
- چی، دبلیو. شی، ال. لیو، ز. Zhu, M. تحقیق در مورد راه حل فنی پلت فرم قوانین کسب و کار و روش مهاجرت قوانین در معماری میکروسرویس. مد. محاسبه کنید. 2021 ، 6 ، 42-45. [ Google Scholar ] [ CrossRef ]
- ژانگ، WT; جین، LK بحث در مورد ساخت و ساز هوشمند آب بر اساس فکر پلت فرم میانی. مهندسی فاضلاب آب 2021 ، 47 ، 538-544. [ Google Scholar ] [ CrossRef ]
- کیو، ا. ژانگ، ی. Luo, N. طراحی و اجرای سیستم خدمات هوشمند کاهش بلایا یکپارچه بر اساس معماری میکروسرویس و مفهوم پلتفرم میانی. Geomat. Inf. علمی دانشگاه ووهان 2020 ، 45 ، 1288-1295. [ Google Scholar ] [ CrossRef ]
- زو، بی. ژانگ، سی. Yu, J. ساخت و کاربرد پلت فرم بازرسی منابع طبیعی بر اساس معماری سکوی میانی. نات. منبع. Informatiz. 2021 ، 1 ، 37-43. [ Google Scholar ]
- چن، اچ. طراحی بر روی پلتفرم میانی تجاری مبتنی بر دامنه محور و میکروسرویس برای سیستم آزمایش شبیه سازی کنترل قطار سریع السیر راه آهن. راه آهن ایستادن. دس 2021 ، 66 ، 1-7. [ Google Scholar ] [ CrossRef ]
- فنگ، دبلیو. تیان، دبلیو. یانگ، دبلیو. طراحی پلتفرم مدیریت اشتراک گذاری مالی بر اساس سرویس میکرو و مفهوم Zhongtai. مالی حساب. Newsl. 2022 ، 6 ، 167-171. [ Google Scholar ] [ CrossRef ]
- Thönes، J. Microservices. IEEE Softw. 2015 ، 32 ، 116. [ Google Scholar ] [ CrossRef ]
- یو، اچ. پلت فرم خدمات منابع اطلاعاتی بر اساس معماری میکروسرویس. علمی تکنولوژی مدیریت Res. 2019 ، 13 ، 211-216. [ Google Scholar ] [ CrossRef ]
- لی، جی. پلتفرم میانی داده چیست؟ Inf. چین 2019 ، 6 ، 72–75. [ Google Scholar ]
شکل 1. معماری پلتفرم میانی بر اساس میکرو سرویس.
شکل 2. معماری پلت فرم تایید اطلاعات مکانی.
شکل 3. معماری فناوری بستر اطلاعات پایه فضای سرزمینی.
شکل 4. مدل تجاری تایید اطلاعات مکانی تایید زمین ساخت و ساز.
شکل 5. فرآیند توسعه عملکرد تأیید تایید زمین ساخت و ساز بر اساس سکوی میانی.
شکل 6. مقایسه معماری در ساخت تابع تایید اطلاعات مکانی در سیستم اعلام یک مرحله ای برای تایید زمین ساخت و ساز: ( الف ) معماری یک سیستم مونومر. ( ب ) معماری سیستم مبتنی بر پلت فرم میانی و میکرو سرویس.
1 نظر