技術跨界的五大關鍵點

文/羅果

    摘自《恆生世界》2016年第四期 和訊網智庫已獲轉載授權

TIPS：技術領域非黑即白的場景少之又少。因此合理的利用技術，有時候甚至要充分利用看起來矛盾的多種技術來共同協作，才能完成挑戰，達成業務目標。

這是一個Cross的時代

以前我們經常說的一個詞是「灰色地帶」，它的本意是指在兩個不同的領域A、B之間有這麼一塊區域，它既有A的特性也有B的特性。

關於波的本質方面，有許多著名的科學家做了大量的研究，有的科學家認為光是一種波,也有一些科學家認為光是一種粒子，兩種觀點都有非常充分的證據，各自發展着。

直到1905年，愛因斯坦發表題為《關於光的產生和轉化的一個推測性觀點》的論文，其觀點認為對於時間的平均值，光表現為波動；對於時間的瞬間值，光表現為粒子性。這是歷史上第一次揭示微觀客體波動性和粒子性的統一，即波粒二象性。這一科學理論最終得到了學術界的廣泛接受。在1921年，愛因斯坦因為"光的波粒二象性"這一成就獲得了諾貝爾物理學獎，這也是光的波粒二向性得到的最大程度的認可。

所以，本來兩群人在為波或是粒撕得不可開交的時候，愛因斯坦結合一下來了一個「波粒」，就拎了一個諾貝爾物理學獎回家，可見Cross的威力。

實際上，早期的軟件領域也是一樣的道理，比如中國著名的BAT，原來B做搜索、A做電子商務、T做IM，大家本來可以井水不犯河水，殊不知一夜之間BAT就拼得你死我活，仿佛不深入到對方的領域就沒法兒活一樣，當然實際情況也確實是如此。

這是一個業務跨界的時代

阿里先是搞了一個「來往」，現在又在搞「釘釘」；騰訊也是在大搞「微信支付」和「財富通」。深究其原因，實際上都是在搶占IM和社交領域、支付相關領域的連接入口。而連接和入口，實際就是一個Cross的領域，它可以引領你從這邊走到那邊，從而演繹着一出「羊毛出在牛身上，讓豬買單」的大戲。

實際上目前在金融領域，商業界限也越來越模糊，原來大家都有各自的領域，但是現在跨界經營越來越成為常態，原來保險是保險、銀行是銀行、證券是證券，而現在這種界限越來越模糊。

確實，對於大多數的人來說，其訴求只是：手里有一些錢，後面還會持續的掙一些錢，怎麼樣合理的利用這些錢讓其在未來的生活中過得更好。理想很美好，但是現實卻很骨感：如果你要享受一個好的收益，就需要懂證券、懂基金、懂理財、懂保險、懂外匯，懂一大堆專業人士也弄不全乎的各種金融知識。所以，對於大多數人來說，現在的各種金融產品太過專業，未來的趨勢一定像恆生的使命說得那樣，讓金融變簡單。這也從另外一個角度說明，以前我們針對不同行業的不同應用場景細分出來的專業產品，未來可能都會整合成一個邏輯意義上的產品，在大數據的支撐下，通過行為分析、用戶畫像及推薦系統，為客戶提供匹配度最好的服務，這樣就可以為客戶提供一站式的金融服務了，當然這個一站式的金融服務平台注定就是跨界的。

這是一個技術跨界的時代

因為我們的金融業務在跨界(證券、基金、理財、保險等等)，並且還要為各種參與者（個人、企業、機構、大V、寬客等等）在各種各樣的終端上（專有終端，Web終端、移動終端）提供各種服務（交易、財富、社交）。在當今時代，技術還想不跨界，怎麼可能？那麼技術如何跨界呢？

1、關系數據庫與非關系數據庫

關系型數據庫已經在各種應用中用了幾十年了，後來隨着互聯網應用的不斷發展，許多非關系型數據庫也不斷的出現，關於這兩種數據庫孰是孰非的爭論甚囂塵上。最終的結果，還是塵歸塵土歸土，在合適的場景和應用需求中選用不同的數據組織形式。當然，有的時候又要有關系型數據的優點又需要有非關系型數據的優點，怎麼辦？那麼就會把數據用多種形式進行存儲，各取所需。

說不定未來可以有一種新的數據庫出來，即有關系數據庫的優點，又有非關系型數據庫的優點，那可能就直接的實現了數據的本源和他的存儲形式的統一，我們可以期待這一天的出現。

2、平台與集成開發環境

要想更好地做一個軟件項目，擁有一個強有力的開發平台支撐可以起到事半功倍的效果，但是一個開發平台一般也離不開強大的集成開發環境支持。那麼問題來了，有些功能（如代碼生成、文檔生成、流程組件等等）看起來是要集成開發環境的功能，但是它實際上又和開發平台有關系，那它究竟應該在哪邊實現呢？我看到過許多流行的商業框架，要麼在開發平台實現，但是這個時候就不方便在集成開發環境中集成，開發人員使用起來不太方便；要麼就在集成開發環境中開發，這個時候就會發現讓集成開發環境的開發人員實現這些功能是多麼的困難，畢竟這並不是他的所長。

因此在我們的實踐過程中，采用的模式是在集成開發環境中定義了集成規范和元數據規范，而真正的實現由平台開發人員按照集成開發環境中定義的開發和集成規范去開發並配置好相應的元數據即可。這也讓平台開發人員和集成開發環境的開發人員各自在各自的領域充分發揮自己的優勢。

在真正運行的時候，集成開發環境可以檢測當前工程中有哪些擴展點並識別和添加到集成開發環境中，看起來就好像是集成開發環境本來就有的功能，而且可以在不同產品中的環境中，更有針對性的出現相關的內容。

3、原生與HTML（含H5）

在CS結構時，原來用Delphi寫界面，後來用C#寫界面，再後來用安卓、IOS上寫原生App；在BS結構時，用各種技術生成HTML來讓瀏覽器來展現。後來就發現：用CS寫的界面開發成本高，變化的時候成本更高；用BS寫的界面執行效率又不夠高，安全性方面較原生App也稍弱。

這個時候一個問題就出現，那能不能既有原生和HTML方式的優勢，又沒有原生和HTML方式的劣勢呢？當問題出現的時候，解決方案也就水到渠成了：二者結合，發揮各自的優點，回避各自的缺點。

4、數據與元數據

其實元數據也是一種數據，它又叫做中介數據、中繼數據等，是描述數據的數據。當一個系統做得比較定制化的時候，實現得什麼功能就是什麼功能，這個時候幾乎是不需要元數據的。但是當一個系統做得越來越有普適性和擴展性的時候，在設計系統的時候，往往無法充分的考慮到所有的情況，也無法完全想得出業務的發展趨勢，不是說唯一不變的就是變化麼，但是系統又不能不做，還不能做出來的時候需求一變化、業務一變化就改，這個時候往往就需要請出元數據的大駕。

只要有了元數據的支持，那麼就可以在出現變化的時候，通過增加一些元數據描配置，各種神奇的事情就可以發生：原來不支持的就支持了，原來沒有的就出現了。所以說，如果要做平台類的產品，元數據確實是非常必要的好東西，它可以被廣泛的應用在界面定義、屬性擴展等等方面。

5、流程化與去流程化

說到工作流的時候，我們原來一定要有專門的流程管理台，待辦任務，已辦任務好吧，貌似流程做得非常好，但是實際上有形的東西做了許多，並不能代表流程化做得非常好。正所謂大音希聲、大像無形，只有把工作流程與業務進行進行有機整合，甚至都看不到工作流程的存在。當然，去流程化實際上還有一個意義，那就是從業務代碼中去掉工作流相關的代碼。業務清清爽爽地做業務工作流，干干凈凈地做工作流。只有這兩個層次都實現了，這個時候才是最好的工作流程實現方案。

所以，我這里說的去流程化並不是指去流程引擎化，實際上實現底層中存在流程引擎是非常正常和合理的。

6、通用功能切面化

許多時候程序員們已經習慣了代碼的復制粘貼，並且把這當成是一種理所當然的事情。這在算人月的項目時代和賣License的產品時代，問題倒都也不太大。第一種有人出錢自然Hold得住；第二種可以賣拷貝，成本也攤得薄，所以也沒有什麼問題。但是在互聯網時代，人員成本不再是最大的成本，時間成本才是。

我們想想看，要給眾多在運行的業務領域都增加一個評論功能，兩種場景的對比：

場景A：做評論的人做好了相關的API，然後找到所有的業務領域的負責人，讓他們安排快速處理，然後所有業務領域的開發人員都在自己的界面中增加評論相關的界面，再在後台的處理中調用評論相關的API來完成相關的處理。開發完畢之後，再調派許多的測試人員進行測試，驗證無誤之後再把所有相關的業務功能上線。這個時候說不定會發現，有的業務中忘記添加評論功能了；許多地方的評論功能界在做得不一致，有的支持超文本，有的只支持純文本；有的測試不到位還有BUG發生。等到所有的問題都處理好了，不僅耗費了大量的人力成本同時時間也過去了很長時間。

場景B：開發評審功能的人開發好相關的前後台功能，測試完成之後部署上線運行，這個時候人多業務功能內自動就出現了評論功能。

實際上許多較通用的功能如IM、社交等功能，都可以采用這種切面化的機制和業務進行集成，真正實現高內聚低耦合，分離開發自動集成。

7、訪問渠道通用化

作為一個金融應用服務平台，自然要向相關方開放一些的服務接口，實際上我們也開放了一些OpenAPI，希望有更多的第三方開發者利用我們的全方位的金融服務來開發更有針對性、人性化、受歡迎的APP。這個時候就需要把我們眾多的服務提供者提供的形形色色的服務對外開放。考慮到接入者的開發語言及運行環境不同，僅僅提供一種服務形式顯然是不夠的，因此就需要有對外提供多種形式服務的能力。

當然，我們也會訪問其他的外部服務提供者的服務，這個時候就需要與這些服務進行對接，由於不同的服務提供者的通信方式、數據傳輸協議都不盡相同，這個時候就要求有強大的整合能力。

實際上由於涉及到內、外的問題，因此流控、安全等等問題就相應出現，這個時候能用通用的方式引入外部的服務，開放內部的服務，同時兼顧到其它關注點還是非常有挑戰性的。

上面提到的內容只能說是幾個點上的心得與體會，實際工作過程中涉及到的要遠遠超過上面寫到的內容。我們已經完成了一些，但是有更多的領域需要我們去學習和探索。歸根到底，技術領域非黑即白的場景少之又少。因此合理的利用技術，有時候甚至要充分利用看起來矛盾的多種技術來共同協作，才能完成挑戰，達成業務目標。