1.引言
企業的信息化應該是因地制宜,循序漸進的過程，好比騎自行車的人還想快些可能就學下電動車或者打輛的士,要一下讓他開上小轎車就是不大現實了。在一些中小企業的”表哥”,“表妹”, 對於不同數據源的excel文件用宏和vba能夠快速靈活的處理和統計。信息化要能貼地氣的解決業務困難,促進業務的發展,選擇最適合自己的方案即可。
2.中小企業的選擇
每個行業現在都有不少雲端的產品,雲ERP,雲OA,雲CRM,雲MES等,協同辦公也有釘釘,企業微信等APP,付出少量的成本如果能解決業務中6到8成的問題還是不錯的選擇。
這類SaaS產品也有一些代價,數據放在別人的雲端,如果對數據敏感可考慮找些開源或免費的產品自己搭建。
3.中大型企業信息化的問題
3.1 採購或自研
大多的企業可能會選擇採購,行業軟件供應商技術和業務都有積累,企業專注於業務數據和流程定義,供應商定製系統。
如何協作得好,採購能解決大多的短期的業務問題,但如果沒一個整體的規劃也會有一些問題。例如一碰到問題就是採購系統,可能多家不同的供應商,每個系統都是解決各自業務域的問題, 例如財務用財務軟件,人事用OA,生產運營用ERP,MES等等, 每個員工每個系統都有一個賬號,業務數據各自為政無法共用。
這個就是阿里提到”煙囪式”系統。隨著互聯網時代的到來,業務從線下到線上,企業內到企業外的交互,結果就是發現這些煙囪要交互起來有困難,如何解決這個問題我們參考3.2。
而自研通常是行業中的大戶的選擇, 這些大企業能夠影響行業的標準和規則。多養一個技術團隊成本看起來是高,但長期的看來,自研才能解決不斷變化的業務需求,保證企業的競爭優勢。
3.2 打通煙囪式的系統傳統方案
供應商更多是以項目形式提供系統,完成各自的業務的邏輯和流程,通常很少提供對應的業務接口,擴展性有限。如果採購就只能協調原有煙囪供應商對接,可能採用的一些方式:
3.2.1 開放各自業務數據庫
開放各自業務數據庫給其它煙囪系統直接採訪,這種方式比較直接暴力,只要瞭解所需業務的數據表定義即可, 但調用方要控制好採訪壓力和資源釋放,別把業務數據庫搞崩了。
這種方式一般在項目比較趕,供應商較難協調時才考慮使用。
3.2.2 開發各自業務接口
每個煙囪首先要開發業務接口供外部調用,例如SAP的PI可開發web service, JCO也可直連調用;Oracle EBS也可以把存儲過程發佈為web service。
不少企業會把ERP作為核心系統,例如SAP,Oracle EBS也支持二次開發不斷的擴展業務, 核心業務放ERP,以ERP為中心打造周邊輔助系統。這是一種風險低些的架構,不過中心化的ERP容易成為瓶頸,像SAP這種集成度越高的ERP沒優化好的情況下,用的人多些就容易卡了,ERP最好能支持應用的均衡負載,數據庫的讀寫分離/集群,甚至分表分庫等方式擴展。
對於對等的煙囪系統業務依賴的時, 簡單些可以直接調用對方開放的接口, 即點對點的調用,實際上現在流行些的微服務/RPC調用也是P2P, 內部的調用未必一定要上服務總線ESB。這種屬於怎麼簡單怎麼搞的解決方案,系統不多的時候開發和維護成本都可控些。
3.2.3 使用ESB整合業務接口
企業服務總線ESB在神壇也有幾年了,以前一談企業集成就基本和ESB扯上了。ESB的存在是SOA實施一個階段的產物。企業採購了一些必需的系統,業務都跑上面積累了不少數據。隨著互聯網的興起等原因要實現系統的互聯互通, 每個系統可能不同供應商,不同的開發語言完成,按照3.2.2開放了各自業務接口後,通信協議可能也五花八門,http/json/web service,socket,甚至專有協議等。對點對的調用在系統和業務多的時候維護成本也不斷增加。
而企業集成開始推崇使用ESB, 參考下Oracle ESB架構圖。
相比點對點的調用,所有的調用都需要到ESB總線路由,數據轉換清理,再分發到對應的服務提供者,對服務消費者來說請求數據格式和通信協議都得到統一和簡化,隱藏了服務提供者實際的實現差異。ESB通常也配套了IDE,拖拖拉拉配置好Inbound, Outbound參數和規則, 少量一些編碼即可對接,大量對接異構系統時效率較高。
無ESB不歡,當時SOA實施的首選基本都是ESB,廠商也投入大量的人力物力高級集成這個總線,讓這個中間件高大上，所以ESB價格不菲。而一般的企業都儘量選擇一些免費或開源的OpenESB, Mule等產品。
ESB是SOA前期探索的產物,從架構上看,它也是一箇中心化的中間件,都經過ESB調用的鏈路長,協議轉換會拖慢些,即使做了均衡負載/集群,在電商等高併發的情況下,SOA調用效率比點對點要低下,也沒法規避ESB雪崩等問題。所以才有了後面的點對點的微服務架構和中臺。
社會和技術都是不斷髮展,ESB雖然慢慢走下神壇,但也在不斷的完善,也還是異構系統整合的一個選擇方案。而且ESB在SOA,也為後面微服務的API網關,服務註冊發現,均衡負載,鏈路監控,日誌等各方面都提供了很多實踐經驗。
3.3 分佈式數據庫在企業信息化落地的探討
企業信息化無論哪種方案,最大的瓶頸應該是數據庫。傳統的關係型數據庫,無論oracle還是mysql單表到一定的數據量後都存在性能問題,所以類似mycat這樣的分片框架流行。
用NoSQL數據庫集群后是傻瓜,不管怎麼分片和存儲,但在開發,設計,功能上的變化一般團隊可能不適應,在級聯查詢,事務,性能等也有一些限制。
分佈式數據庫這幾年開始穩下來,以阿里的Ocean Base和PingCAP的TiDB出名些,當然商用版的MySQL Cluster也算分佈式數據庫, 主要開發設計不用考慮數據分片,mycat都可以回家了。
對於中小企業的信息化,基於分佈式數據庫就省事了,可以傻瓜的認為用一個數據庫存儲所有數據,多個系統公用這個數據庫。這種也是屬於怎麼簡單怎麼搞的方案,有點粗暴,這裡是拋磚引玉。
不過個人比較看好Ocean Base,性能可以,這個基礎設施講不好真能幹掉oracle。
4 企業信息化是否使用中臺架構?
4.1 阿里中臺介紹
以阿里為首的互聯網和電商帶火了微服務和中臺, SOA又到了新的階段。
阿里以前其實很造了很多煙囪,例如淘寶,天貓,1688,每個大部門自己玩自己的系統和數據。後面業務整合需要數據互通,就成立了共享業務事業部, 慢慢就開始了厚中臺,薄應用的轉型之路。費了大量人力物力之後,慢慢的共享服務的好處越來越明顯。 新增個業務例如造個鹹魚,用戶有了,商品等基礎數據有了,很多業務不需要重複建設,充分的重用服務和資源。
這基本成為互聯網公司的標杆了,業務中臺,數據中臺。
4.2 企業信息化是否需要中臺?
文章開篇的一個準則,如果業務碰到問題,中臺能更好的推動業務發展,則可以考慮。
中臺是為了重用業務服務,減少重複建設, 它的實施基於分佈式服務化框架。技術層面的也需要解決很多問題, 服務如何拆分,數據庫如何分表分庫, 開發人員分工的變化,服務接口如何通用, 分佈式事務如何處理, 鏈路日誌監控, 限流降級熔斷,自動化持久集成和運維部署。對產品,開發,運維，工作量暴增,中臺的成本是昂貴的。
阿里的中臺也是一個過程,單體應用,到ESB打通煙囪,他們都經歷過。 所以說企業的業務積累到一個度了,無論是上什麼架構, 都是水到渠成的事情。企業的老總或者不怎麼懂技術,但是業務的思考都是行家。再好的技術如果不能推動企業業務的發展帶來好處,也是沒意義的。
閱讀更多 耕雲不盡釣月無痕 的文章
