整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
要安裝JDK和Android Studio
1.JDK
https://www.oracle.com/java/technologies/downloads/
2.Android Studio
Android官網： https://developer.android.com/index.html
不出戶、手機為伴、網劇相隨、居家辦公
宅宅宅的日子轉眼已經到了二月中下旬
足不出戶的你
是不是眼看要面臨買電、交網費、駕駛證更換的問題……
居家辦公的你
是不是也得要完成單位報稅、繳納員工社保的工作……
一邊要乖乖宅在家中
另一邊這些事情又亟待解決
有沒有二者兼顧之法呢？當然有！
下面這份居家必備
能讓你足不出戶解決燃眉之急
網上辦電一次都不用跑
在疫情防控的關鍵時期，國網新疆電力有限公司全面推廣“網上辦電”，提供7×24小時在線服務，通過“網上國網”APP、國網新疆電力微信公眾平臺、95598熱線等渠道，全面推廣、積極引導在線辦電服務。
為最大限度做到“不見面”辦電，該公司從業務受理、現場勘查、方案答復和驗收送電等各環節嚴格把控，對于需要客戶上門的供電方案確認、供用電合同簽訂、電費發票打印等業務，改為引導客戶通過“網上國網”APP進行線上操作；對于增值稅專用發票打印的業務，與客戶協商通過郵寄等不見面方式解決；對于減容、暫停、減容恢復、暫停恢復等需要，通過線上渠道進行業務指導、資料傳遞，運用微信定位、視頻功能減少到場次數。
“網上國網”APP，可辦理電費交納、賬單查詢、故障報修、辦電申請等79項用電業務。同時，根據客戶特點和不同需求，設計“住宅、電動車、店鋪、企事業、新能源”5個專屬服務頻道，針對不同客戶提供不同服務功能，實現不同客戶多元需求“一網通辦”，真正實現讓客戶“一次都不跑”。
國網新疆電力有限公司營銷部張超介紹說：“疫情防控期間，公司積極推廣‘線上交費’，現已開通的線上交費渠道有網上國網、電e寶、微信、支付寶、電費網銀等8種模式，做到‘網上辦、不見面、保安全、效率高’。”
涉稅業務 網上辦理即可
目前針對常見涉稅業務均可通過新疆電子稅務局或手機APP辦理。納稅人可登錄新疆電子稅務局網址：http://etax.xinjiang.chinatax.gov.cn/wszxweb/bszm/apps/views/beforeLogin/indexBefore/pageIndex.html，下載新疆稅務手機APP，（下載方式：登錄新疆稅務電子稅務局——公眾服務——下載服務——軟件——新疆稅務手機APP），如需要咨詢涉稅問題，可撥打新疆稅務局12366納稅服務熱線咨詢。
如果需要辦理個人所得稅相關業務，代扣代繳義務人請使用自然人電子稅務局扣繳客戶端辦理相關代扣代繳業務。自然人可以登錄自然人電子稅務局https://etax.chinatax.gov.cn或使用個人所得稅手機APP辦理經營所得申報與繳款、申報記錄查詢、專項附加扣除采集等業務。個人所得稅手機APP在各手機應用商城中搜索“個人所得稅”，下載安裝即可。
如果需要辦理社會保險費繳費，可通過銀行智能POS機、銀行自助終端、新疆稅務電子稅務局、新疆稅務手機APP、新疆稅務社保繳費微信小程序、建設銀行“裕農通”、手機銀行APP、社保費代扣客戶端等方式辦理，具體詳情請查看新疆稅務微信公眾號發布《關于城鄉居民社會保險費多元化征繳渠道情況的通告》 。
社保業務“不見面” 網上掌上一樣辦
記者從自治區社會保險管理局了解到，對于單位而言，目前多項業務均可網上辦理。參保單位可通過網上經辦大廳進行“無變動提交”，實現當月社保費繳納；參保人員增減變動、社會保險繳費基數申報業務，參保單位通過網上經辦大廳提業務申請，相關資料通過郵寄或傳真方式送達自治區社保局機關事業中心，審核通過后電話告知業務辦理完結，單位即可通過網上經辦大廳繳費；對于企業參保人員社保關系轉移接續的，參保單位可將相關人員社保關系轉移申請發送傳真至自治區社保局機關事業中心，通過人社部社保關系轉移接續平臺為參保人員辦理相關業務。
參保單位無法通過網上經辦大廳辦理的業務還可通過電話申請，包括社會保險費繳納、退休人員待遇暫停業務、職業年金申拔、企業參保人員退休手續辦理、社保卡變更，業務咨詢等。
自治區社保局機關事業中心工作人員提示：疫情防控期間，我區社保業務均可以通過自治區一體化政務平臺、自治區人社廳官網網上經辦大廳、新疆智慧人社手機APP、12333咨詢服務電話等途徑網上、掌上以及電話辦理。
交管12123 車駕管業務在家辦
宅在家中足不出戶，雖然愛車可以不用上路，但是和機動車、駕駛人、駕駛證有關的業務卻沒有停歇，此時通過登錄交通管理互聯網綜合應用平臺或者下載”交管12123”APP，實名注冊后即可辦理相關業務。
目前，“交管12123”為互聯網平臺注冊用戶提供的主要服務內容包括交通安全信息查詢類：機動車、駕駛證、道路交通違法信息等。交管業務辦理類：機動車選號、補換領機動車號牌、補換領機動車行駛證、申領免檢標志、期滿換證、遺失補證、考試預約、考試費繳納、交通違法處理、罰款繳納等。以及用戶信息管理類：用戶注冊、實人認證、綁定本人機動車、備案非本人機動車、聯系方式變更等。
另外，“交管12123”APP上可處理以下交通違法：1、本人名下或非本人名下已備案的機動車非現場違法行為，可通過帶銀聯標識銀行卡在線繳納罰款；2、警告或200元以下，記分為6分（含）以下罰款的非現場違法行為；3、非本人已備案的機動車有記分的非現場違法行為時，只允許處理在備案日之后發生的違法行為；4、通過“罰款繳納”功能自助繳納民警現場處罰的交通違法。
話費、網費、電視費 手機在手輕松繳
目前，新疆各家通信企業通過在線自助繳費，以及各項通信服務在線辦理的方式，讓用戶足不出戶即可享受到各項通信服務，并實現線上繳納話費、網費、電視費。
新疆電信用戶可以通過下載“電信營業廳”手機APP或者關注“中國電信新疆公司”和“中國電信新疆公司客服”微信公眾號享用隨時隨地自助服務。
新疆聯通用戶可以通過下載并登錄中國聯通手機營業廳APP，足不出戶，輕松交話費、辦業務、查余額，還可訂購流量包、視頻會員服務、寬帶等業務。還可以通過關注并綁定“新疆聯通”微信公眾號，通過底部標簽欄“我要辦理”—“話費充值”，居家隨時都可進行話費直充。
新疆移動可提供多渠道充值交費方式，中國移動APP：移動用戶可點擊：https://10086.cn/d/7vInEv 下載；移動商城觸屏版：https://touch.10086.cn/i/mobile/rechargecredit.html ；新疆移動微信公眾號：微信關注"新疆移動"，充值交費可享受9.98折優惠。
新疆廣電網絡用戶可以通過關注新疆廣電網絡微信公眾號→點擊“自助服務”→點擊“充值繳費”，綁定智能卡后即可充值。
（記者 劉昕 張冬梅 費璇 馬蓓 任春香 通訊員 周廣科）
者丨榮多君
互聯網時代演進到現在，在 5G 和 IOT 的影響下，整個人類社會實現全產業數字互聯的愿景變得逐漸清晰，某個行業通過行業標準的制定，采用同一套標準，甚至同一套軟件，通過行業領域能力的復用，來快速構建產業平臺，并通過需求的更新與場景的優化，來不斷積累行業的量變，最終形成質變。而 B 端，正是實現產業數字互聯的重要組成部分，因此，以 AT 為代表的大廠都開始把目光指向了 B 端。
與傳統的 B 端軟件交付廠商不同，各互聯網大廠憑借雄厚的產品與技術實力，大都已完成 C 端的業務與技術基礎設施建設，因為技術具有通用性，因此，暨希望通過現有產品和技術進行小規模的改造，來滿足 B 端（Saas 化或私有云）交付和部署，便成為各個廠商的普遍思路。
但要真正走向 B 端，做好賦能和服務，還會面臨許多困難。
簡而言之，就是要解決“集成與被集成”的問題。
2.1. 集成與被集成
對 to B 領域的認識很容易陷入到無邊界的陷阱中，從技術和產品的角度去評估會認為都可以做，實際上進入更廣泛的領域之后，會發現各行各業大多都有自己獨特的知識體系和產品，一套體驗、一套流程、一套配置很難包打天下。這時，廠商就會考慮更新戰略，重塑業務邊界，通過引入 SI 與 ISV 來構建產品生態。
引入 SI 與 ISV，除了是一種思想戰略的轉變，同時也是技術的變革，是從提供一個從頭到尾的完整解決方案，變為別人解決方案的一部分，成為 inside，實際上要求是更高了，包含了從產品的被集成，到技術的被集成，到生態的被集成。
2.2. 被集成的難點
本文主要談技術方面。
以近些年，互聯網企業在 To B 領域的實施情況來看，很多成功都是依靠投入很多精兵強將才做成的，說明互聯網企業，其技術面對復雜場景，離標準化輸出、快速復用、方便二開還有一定的距離。To B 解決方案無論是在公有云還是專有云上，和自有技術產品實施相比，存在很多差異和問題：
To B 的產品能否成功，取決于生態，生態取決于能否吸引到 ISV 和 SI，而吸引到 ISV 和 SI 的關鍵環節，在于平臺能否滿足 ISV 和 SI 的需求。
落到更細節的技術方面，SI 與 ISV 需要什么？
靈活定制：前后端都提供靈活的二開機制，前端提供搭積木的自由組裝的能力；后端提供靈活的功能擴展能力，能夠將定制代碼與核心代碼完全分離；同時支持流程定制、元數據擴展、服務編排。
快速交付：盡快產出原型（方便復用）、盡快交付產品（積木式、配置化地組合業務，基于基線能力快速地擴展和定制能力）。
提高生產率：提供功能完整的應用開發平臺，并提供主流 IDE、Maven 插件來提升開發效率效率，基于 CICD 平臺來實現打包部署自動化。To B 端常見的表單和列表的 CRUD，能夠直接根據視圖生成邏輯并映射到數據對象和物理表。
WORA：Write Once，Run Anywhere，前端一套代碼能夠在 PC、Mobile、小程序運行（Electron、flutter、taro1.3 等框架提供了技術上的可行性）。
Hotpatch：以往比較成熟的方案是移動端基于 jspatch、multiDex 等方案實現 hotpatch，但由于 ios 管控及小程序生態的崛起，目前小程序化成為 hotpatch 的主流選擇。
運行時態可配置：提供線上前后端的配置平臺，實時生效。
使用門檻低：提供所見即所得的開發 IDE，并且支持各種主流語言。
學習成本低：可視化開發平臺；完備的文檔、Demo、視頻；使用引導和幫助；playground、官網或開發者社區。
可以看到，To B 的軟件開發考慮的維度要多于自有產品技術實施，它所面對的不僅僅是有和無的問題，關鍵在于平臺的整合建設，這么說，未來 To B 戰場的，誰最先整合出領域技術平臺，誰就能握有生態，誰就能成為事實上的標準和規范。
2.3 解決難點要考慮的方面
要設計一個解決 ISV 和 SI 的痛點、滿足業務開發和擴展的需要，具備靈活的二開能力，并且方便使用的 To B 應用開發平臺，需要考慮很多方面：
首先，從分層的角度來看，管理一個 To B 的產品或解決方案，要有一個可視化的研發過程管理平臺
向 ISV 及 SI 提供統一的研發過程管理平臺、注入統一的開發流程和理念是非常有必要的，這不僅可以降低合作伙伴接入生態的難度，也可以增強 ISV 和 SI 進行項目開發的規范性；同時基于平臺對項目過程數據進行結構化地存儲，以利于后續利用大數據進行效率、利潤、成本的核算。這個研發過程管理平臺包括項目管理功能，同時對接前端和后端平臺進行開發，并且提供質量管理和人員管理的工具，最后可以方便對解決方案和項目進行集成和發布。
其次，平臺整體架構應該如何分層，各層的數據模型應該如何定義，數據模型之間如何進行映射和轉化。比如前端與業務后端的銜接，定義一套標準的 View Object 對象（包括擴展標簽），由 API GW 進行解耦，通過視圖 id 或 name 進行數據操作。再次，ISV 與 SI 的客戶定制代碼與核心產品代碼如何完全隔離，這里涉及到兩個二方面：
然后，業務流程如何編排，這里業界有不同的做法，本文中推薦在前端基于組件實現可視化的業務流，在微服務的架構下，前端組件一般 1v1 對應后端接口，通過用可視化（組件之間的關系連線）方式定義前端組件之間的調用關系，間接建立后端功能流程的調用鏈。
再后，基于 API 網關實現前后端的分離，實現接口級別的熔斷、權限、安全、降級等策略；同時提供日志管理和異常監控（包括穩定性監控和業務異常監控）。
最后，基于 CICD 平臺，能夠基于 yaml 將前后端應用單個或整體快速拉起，以實現解決方案級別的快速部署和升級。同時自動將產品的功能模塊沉淀回中臺，并將項目過程數據作結構化存儲，作為二次開發的基礎能力。
根據 2.3 的考慮，一個完整的 To B 應用開發平臺架構總體可以劃分為 5 個部分，分別是項目管理層、前端拼裝層、后端能力層、底層框架和 Runtime Infrastructure。
項目管理層主要是提供一個研發過程管理平臺，方便 ISV 和 SI 可視化管理項目和需求，對接 Runtime Infrastructure，并提供前后端開發工具。
前端拼裝層分為二部分，基礎部分與 APIGW 對接，基于 VO 建模，可視化配置和綁定業務能力接口；拼裝部分基于可視化編輯器提供前端組件的積木式組裝。
后端能力層分為二部分，基礎能力封裝業務核心代碼，用于快速構建基線能力；定制能力主要基于 SDK 進行定制開發，基于 SPI 擴展點，利用多態特性實現定制。
開發框架主要是提供 SDK（封裝注解及定義）方便定制開發、vs studio plugin 和 maven 插件用于打包發布。
Runtime Infrastructure 包括 CICD、日志、運行監控、自動化測試等能力。
一、研發過程管理平臺的架構設計方案
除了編碼采用線下開發（提供必要的 plugin、sdk，如果部署方式走 serverless，可以考慮集成 monaco 進行定制，實現線上 coding->compile->test->deploy 一體化），其它包括項目管理、需求管理、版本管理、工程管理均可在該平臺上集成并進行日常管理。同時，研發過程管理平臺還可通過對接前端開發平臺、后端開發平臺、CICD 平臺、質量管理平臺、帳戶體系形成一個完整的應用開發 studio。
二、前端業務組件拼裝的架構設計方案
裝修編輯器：提供支持相對布局\絕對布局的編輯器，提供包括頁面布局調整、樣式調整、組件拖拽展示、預覽、屬性設置在內的所見即所得的功能體驗。
復用沉淀機制：前端拼裝的基本粒度是業務組件，能完成具體業務動作的，與后端能?連接的（可選）業務組件，? ?交互 / 基礎組件。舉例來說，商品列表、購物車、買家訂單列表都是前端拼裝中的組件，? Button 、Input 、Toast 等屬于基礎組件（Base Component），不是前端拼裝會操作的組件級別。版本發布時，新開發或修改的組件經過 webpack 打包成 npm 包，上傳 npm 倉庫，用于下次開發復用。
業務流編輯器：用于描述前端組件之間關聯關系的編輯器（所謂關聯關系，目前可以淺顯地表現為組件跳轉顯示關系，實際上由于每個業務組件都與后端 API 關聯，也代表了后端的調用流程），提供 4 種基礎概念元件，分別為 Process、Branch、Begin、End，每個概念元件均可以綁定特定業務組件，在編輯器上將概念元件連線，然后通過組件內部實現的“出入口”機制，實現組件與組件之間的跳轉關系。
頁面管理：頁面在業務組件化的前端系統中，作為業務組件的容器，承載布局信息。
后端服務綁定：每個組件都能有選擇地綁定 1 到多個后端 API，當點擊該組件中某個控件的響應操作時，會觸發對后端 API 的調用。這樣的好處是，解決方案部署的同時復用了前后端的功能和體驗，可以快速生成原型或交付件。
同時，為了提升開發體驗和效率，需要配套提供開發 SDK、集成開發環境的插件（vsc plugin 等）、以及包括配置、告警、監控、A/B Test 等在內的公共基礎能力。
三、后端開放性架構設計方案
由后端服務提供服務 SDK，前端組件通過該 SDK 對后端網關暴露的 API 進行綁定，事實上建立了業務組件與后端服務的關聯關系，這種綁定方式是去代碼化的，并且基于精巧設計的、對象化的、功能兼容的接口（例如 graphql）可以實現動態切換（免代碼修改）。
Domain Service（領域服務）通過對領域功能和流程進行抽象，提供基線（標準）功能，并對領域數據封裝原子級別的操作入口。
Business Service（業務服務 / 定制服務）基于 Domain Service 提供的擴展點（SPI）實現功能和流程的定制。
Domain 和 Business 可以實現完全的代碼隔離，這對于生態的知識產權保護非常關鍵。
DB 和數據訪問層主要作用是對 Domain 標準定義進行領域數據建模，同時針對業務提供數據建模的擴展能力，并且服務于 B 端，還需要充分考慮租戶間數據隔離和數據跨應用聯通的方案。
3.1 前端的開放性設計
前端的開放性設計涉及到 4 個維度：業務組件、沉淀與復用、業務流、組件的擴展。
3.1.1 組件業務化及跨平臺化
這里的業務組件，如前面所述，是能夠觸發或完成一個業務動作、與后端能力連接的業務組件，??交互 / 基礎組件。這樣，一個業務組件實際上封裝了端到端的邏輯（前端的操作、體驗，后端的功能、數據）。使用一個業務組件，實際上也使用了與其綁定的后端能力和數據
另外，由于 To B 市場在端側的多樣性，從成本的現實考慮，前端組件跨平臺的需求也非常常見，近幾年，由于 Electron、微信小程序、RN\Weex 等技術的成熟，類 html+css+js 已經成為事實上跨多端的首選技術。
PC 端與 Mobile 端由于體驗的差異，組件往往不能共享，但通過一定的表現式語法抽象（suning DSL），通過提供 DSL parse sdk 對抽象語法解析，提供更高層次響應式的解釋和適配（如，在 PC 端可以解釋渲染為 List，在 Mobile 端可以解釋渲染為 ListView），可以在一定條件下實現 Write Once Run Anywhere。
3.1.2 沉淀與復用
前端工程在開發之初，定義 PRD（這種 PRD 是一種電子化的，可結構化定義并存儲的 PRD），并在平臺上創建解決方案。
復用：新迭代或新應用開發時，根據業務需求，可以到業務組件倉庫中尋找（類似于 AppStore），如果是已有且可復用能力，則由平臺直接添加 NPM 依賴到對應開發工程中，對于不具備的能力，標識為 todo。
沉淀：當業務組件開發完成，通過在 CICD 平臺配置腳本，同時沉淀業務組件的 NPM 包，并更新 PRD，為下次復用準備。
這種沉淀和復用機制，以業務功能維度進行，實現了代碼的完全隔離，并依賴平臺，可實現完全的自動化。
3.1.3 業務流
單獨對組件粒度進行復用依然會帶來不必要的重復工作量，同時組件間也需要?種機制進行串聯。頁面組是?種?式，將?個高度相關的頁面做成?個頁面組，彼此通過相對 url 串聯。但某些交叉頁面（例如商家后臺首頁）可能會是多個業務行為的入口，包含多個業務組件，如果有關系的頁面都做成頁面組，那?個頁面組可能會包含很多個業務?為；如果將這種交叉頁面從頁面組中拿掉，?會導致頁面組本身不完整；后臺系統較少交叉頁面，而前臺系統會有很多。所以通過定義業務流（操作流），并定義等價組件（Equivalent Component），來解決上面的問題，使分解?個站點成為多個業務行為并再組合成為可能。
3.1.4 組件的擴展
首先，通常的業務組件，其邊界是模糊的，并且與應用頁面的緊密耦合，導致其無法被內聚實現，并進行復用。其原因主要有兩點：
1、應?內邏輯由 url 串聯，url 屬于應?全局的信息，但會出現在業務組件內部；
2、使?全局狀態管理，組件間共享狀態，但往往未經過良好 設計，導致組件間有隱式的互相依賴；
因此，需要將顯式的 url 從組件內移除，引入出口概念，組件自定義出口（行為和參數），將出口行為和出口目標分離，并提供業務組件級別的狀態管理，狀態可在業務組件內的繼承組件間共享，但不可以在業務組件間共享。
其次，由于組件具有業務屬性，而業務之間往往存在一種固有的流程機制（如加車 ->下單 ->支付），通常的方案，是建立一組 Page 的集合（Page Group），彼此通過相對 url 建立關聯。但某些 Page 包含多個業務行為的入口（如首頁樓層），如果有關系的 Page 都做成 Page Group，那一個 Page Group 可能會包含很多個業務行為，無法復用；如果將這種場景排除掉，又會導致方案本身的不完整。因此，基于頁面來復用這種業務關聯是不合適的（如前所說，Page 只是一種容器）如果建立一種串聯機制，可以動態地定義業務組件之間的關系，便可以脫離 Page 的限制，實現真正的解耦。
因此，可以引入業務流（操作流）的概念，動態地定義組件之間的關聯關系，使復雜業務關系的復用和重組成為可能。
業務流（操作流）是一組具有關聯關系的業務組件的集合，通過數據結構定義組件之間的關聯關系，通過這種方式將業務流觸發條件和行為封裝在操作流內部，不再受 UI 變化的影響，也就規避了以往頁面變化時，url 和調用方式需要重新實現的問題。
實現組件間跳轉的邏輯：
1、Component 描述出口方法和數據對象
2、在業務流（Business Unit）中獲取 SourceComponent 組件的出口 output 定義，執行 output 方法，命中 TargetComponent。
3、獲取 TargetComponent 所在的 Page，匹配 output 或 URL，設定跳轉方式，并執行跳轉。
最后，來講一下組件本身的擴展。
UI 的實時響應式擴展：依賴于 React\Vue\Angular 等響應式前端框架，利用組件的單向 / 雙向數據綁定能力，當組件的屬性發生變化時，VDOM 會對變更部分進行實時的局部渲染。利用這個特性，我們可以設計一種組件的 Setter 機制，這是一種屬性的注入器，利用 js 實現，當變更組件的某個屬性，比如背景色、分欄、圖片等，可以實時地對反饋到組件的展現部分。對于功能部分的擴展：可以對組件現有能力進行兼容或非兼容性升級，重新發布到線上，并通過組件更新機制來實現功能擴展。
3.2 后端的開放性設計
前端組件應對了業務場景化需求，但這個復用顆粒度對于業務邏輯和數據而言仍然比較粗，因為即使是不同的場景，內部的邏輯和數據結構依然可以復用。而且，后端大都采用了微服務架構，各系統提供了原子接口，不同的原子接口匯聚成一個個標準業務流程，但在 To B 的生態中，定制與擴展的場景很常見，比如：
基線提供的業務流程，在交付給 A 和 B 的過程中，都有存在定制變更的可能性，當然，對于這種場景，可以通過在基線中做個功能全集，然后定義不同的業務參數或配置來開關，但還有些場景是開關和配置無法滿足的，比如互斥和擴展的場景：
這個時候，要么拉分支自己改，但這樣做后續代碼分支多了很難合并收斂，增加運維成本；如果讓 ISV 和 SI 維護分支，又冒著核心代碼公開的風險。
因此，如果能設計一種靈活二開的后端開發框架，由 ISV 和 SI 根據業務定制需求進行擴展，便有了必要性。
3.2.1 架構和流程
將后端服務劃分為：網關、業務定制層和基礎能力層。其中網關主要作用是對外暴露 API，Business 和 Domain 的服務都負責各自領域的業務建模，包括自己的元數據建模和視圖建模，Business 和 Domain 都對外提供服務，不同的是，Domain 提供提 SPI，是可復用、可擴展的點。而 Business 可以提供 SPI，也可以提供 API，視具備策略而定。
上圖是一個二開的示意流程，在每個變更點，添加待實現的 SPI，并在平臺結構化落庫。在網關上添加（新增）或修改（現有）API，指向該 SPI，此時，前端可以在平臺上查詢到該新增的 API。通過元數據建模和視圖建模，并結構化存儲到平臺上，前端可通過平臺查詢到視圖信息，根據視圖的 schema 可以進行前端開發。后端則實現該 SPI，并通過 CICD 發布沉淀到平臺中，用于交付及后續復用。
3.2.2 SPI
SPI 是后端框架實現開發性設計的關鍵元素，它由服務的提供者來定義，確定命名空間、方法名、出入參，平臺上的 SPI 可以簡單對應到 java 世界中一個單方法的 interface。
Business 和 Domain 對外暴露 SPI（Business 可以暴露 API），通過對 SPI 定義、迭代、調度、復用和沉淀實現能力的開放。
注解：
@BusinessSPI 業務應用層 SPI 注解
@DomainSPI 領域中心層 SPI 注解
SPI 定義的步驟：
1、從平臺上創建的 git repo 上 clone 到可開發的 maven 工程
2、在工程目錄的對應目錄中編寫 spi 定義，并加上 @SPI 注解
3、命名工程中提供的 maven 插件打包，插件會將 spi 信息抽取并提交到平臺。
4、平臺會生成實際可用的 jar 并發布到 maven 倉庫，返回操作成功與否等信息，開發者可以在編譯打印中查看。
SPI 定義的示例：
通過定義 SPI 對外暴露各類可定制點，利用 java 的多態性，針對不同的業務場景定制不同的 Impl。在實際的使用中，框架還需要支持 version、多租戶等層面的信息，用于確保路由的正確性。
目前的二開，主要是通過 SPI 的機制，在現有產品和解決方案的 Domain 能力基礎上進行覆寫或擴展，實際使用中，可能存在以下幾種情況：
1、給定的 SPI 抽象準確，現有的實現代碼滿足要求，則直接使用現有鏡像。
2、給定的 SPI 抽象準確，現有的實現無法滿足要求，則重寫一個新實現。
3、給定的 SPI 抽象不準確，邏輯無法滿足要求，則定義一個新的 SPI 并實現。實際使用場景中，@注解還可以細分成多種：
1）命令式申明注解 @BusinessCMDSPI、@DomainCMDSPI
2）查詢式申明注解 @BusinessQuerySPI、@DomainQuerySPI
3.2.3 元數據
元數據提供 @Entity 注解來申明定義。
元數據不支持嵌套（主要是因為復雜，同時不是必要），一個 Entity 內部的成員變量不能是 Entity。
元數據參數存儲上支持字段擴展，采用屬性值表設計，原來應用配置的數據源會退化為元數據后端的地址；元數據后端提供視圖映射功能，可以針對元數據直接做聚合查詢，并直接生成 SPI 及對應 SPI 的實現代碼。
Entity 定義后實際可能會映射到多張物理表，整體方案從技術上來說，主要難度在于事務處理上，目前來看短期內沒法構建一套可靠穩定的方案，因此，操作內部實現目前走 mapper 并直連數據源，但對外暴露統一的 load/save 方法。
定義及沉淀流程：
1、開發時，定義 Entity 并申明 @Entity 注解，通過 IDE 插件解析注解，將本地元數據定義 DSL Push 到平臺服務，平臺根據定義自動識別變更、合法性，生成物理庫表。
2、IDE 插件提供一套類似 lombok 的編譯器修改抽象語法樹的機制，給元數據提供 load/save 等方法。
3、增加元數據 save 擴展點方便 handle 業務代碼插入。
4、運行時，具體的 load 和 save 方法會調用元數據后端提供的 RPC 服務。
5、發布時，元數據地根據 Application+ 類名，并變更自動生成的版本號。
3.2.4. 視圖
在 To B 的應用中，表單和列表占據半壁江山，可以針對典型的中后臺應用表單進行抽象，輸出一份通用 scheme，基于該 scheme 進行視圖建模。
業務上很多場景化查詢需求，如果這部分實現全部落到 Domain 層，對 Domain 層的穩定性是個沖擊，視圖建模和視圖查詢主要應對這些場景。
在后端平臺側提供視圖建模功能，可以自由搜索元數據，選擇需要的字段，組合成新的視圖，開發人員需要給出元數據字段到視圖字段的 mapping 關系，以及指定視圖的 id 作為唯一標識，并進行發布。
發布后，平臺自動生成對應的 @BusinessSPI 或 @BusinessQuerySPI 定義和實現，package 成 jar，并 Push 到 maven，對應視圖的查詢和簡單的 CRUD 結果集便可自動生成。
如果修改視圖，在平臺上修改視圖字段，平臺重新生成相關的查詢 SPI 和實現，并自動變更視圖 version。
在視圖關聯數據庫方面，如果采用的是物理庫表，則可能會出現一個視圖對應關聯多個庫表聯合查詢的情況，這個邏輯比較復雜，考慮了 2 種方案：
1、落到 es 進行查詢，走 mysql->canal->es 的方案
2、走邏輯大寬表方案
3.3 前后端的銜接設計
同步 VO 與根據 VO 獲取數據進行分離，由 API GW 進行解耦，通過視圖 id 或 name 進行數據操作。前端通過特定接口獲取到該應用的所有 vo，并進行列表展現。每個 vo 都有對應的 version，用于同步 VO 的變更。
前端平臺提供 loader 或 parser 解析視圖 VO，反向渲染生成組件。
后端平臺通過搜索元數據，選擇需要的字段，組合成新的數據視圖 -DO，后端平臺自動生成對應的 @BusinessSPI 或 @BusinessQuerySPI 定義和實現，package 成 jar，并 Push 到 maven，開發本地應用。（對于某些 VO 和 DO 直接一對一映射的場景，前端也可以考慮直接使用 DO）
根據上圖，開發平臺的基本流程和各層功能為：
1、基本流程：數據對象 DO->SPI->API->展現視圖 VO->組件 ->UI，前端業務組件直接與后端 SPI 及數據對象進行映射。
2、前端拼裝：
1) 提供編輯器，支持絕對布局和相對布局，可以由 VO 直接生成業務組件；也可以采用類 Axure 手工拼裝成組件，并綁定后端 API。
2) 支持基于現有業務組件，通過業務流（操作流）和 Setter 機制來擴展組件能力。
3、后端能力：在 Business 和 Domain 都支持通過 SPI 來定義服務的擴展點，ISV 和 SI 可以在不修改原有邏輯的基礎上，通過替換 SPI 來實現功能的替換、升級和擴展。
4、數據層面：通過將前端組件與后端 SPI 及數據對象進行映射，若對元數據對象進行新增或變更時：
1）可以直接動態變更 UI 的展現形式和內容，無須修改前后端代碼
2）通過定義數據視圖，能夠根據業務訴求，對不同元數據進行聚類、組合、以實現運算的目的，同時能夠以不同的組件形式對后端數據進行展現
從云計算的發展趨勢來看，從 Iaas 開始，未來必將在 Saas 結束（Paas 因為包括各種標準化組織和開源社區的存在，未來少有溢價的可能）。而 Saas 也是議價空間和增值空間最多的地方，未來哪家企業能夠首先完成對各個行業和領域的在核心生產流程和業務抽象，整合更多更優秀的 ISV 和 SI 資源、甚至社區的力量，誰就能成為事實上的標準。
對于 To B 領域的玩家，應該走開放生態的道路，做生態，就是做標準；做平臺，就是做信任；做開放，就是做共贏。
作者簡介
榮多君，蘇寧科技集團 O2O 平臺研發中心副總監，多年 ICT 及互聯網工作經驗，曾先后就職于華為、阿里巴巴，現在蘇寧從事 O2O 新零售業務及平臺的建設，擅長前后端主流技術、移動互聯網平臺建設及服務治理、云原生及中臺技術。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
