我們公司涉足電商多年，以前根據(jù)業(yè)務(wù)轉(zhuǎn)型或拓展單獨開發(fā)過多個類型的電商平臺，目前面臨舊平臺資源無法整合，拓展新業(yè)務(wù)發(fā)開新平臺又要重新再寫一些邏輯相似的業(yè)務(wù)代碼。所以我們內(nèi)部急需這樣一個整合所有基礎(chǔ)服務(wù)的內(nèi)部SOA平臺殃饿。本博文就是我在架構(gòu)這個平臺的經(jīng)驗分享。
一芋肠、電商類的內(nèi)部SOA平臺需要做什么
首先乎芳，SOA即面向服務(wù)的架構(gòu)，絕大多數(shù)電商平臺不外乎用戶帖池、商品秒咐、訂單等基礎(chǔ)服務(wù)，以及一些發(fā)送短信碘裕、驗證碼等通用工具類服務(wù)携取。那么這個內(nèi)部SOA平臺的作用就是整合這些資源，由他向上層平臺提供服務(wù)帮孔，同時可以讓用戶雷滋、商品不撑、訂單等數(shù)據(jù)在所有平臺內(nèi)共享。
通過這個SOA平臺可以將業(yè)務(wù)分割晤斩，交由不同的部門管理維護焕檬，其次拓展的新業(yè)務(wù)可以做到快速開發(fā)上線。例如A平臺僅需實現(xiàn)自己業(yè)務(wù)A獨特的需求即可澳泵，用戶实愚、商品、訂單等服務(wù)可以調(diào)用SOA平臺的兔辅。
二腊敲、基于RPC的電商平臺內(nèi)部SOA架構(gòu)及組件選型
下圖是我初步設(shè)計的SOA平臺架構(gòu)圖以及一些組件的選擇
1. RPC框架的選擇
RPC即遠程過程調(diào)用，通俗一點就是跨進程跨主機的通信協(xié)議维苔，用在SOA平臺與上層業(yè)務(wù)平臺之間的通信碰辅。
其實傳統(tǒng)的webservice、rest服務(wù)都是RPC的一種介时。但是這些基于HTTP+JSON/XML的通信方式效率不高没宾。但是由于他們的通用性以及易開發(fā)的特性使得他們更適合對外第三方接口的開發(fā)。
作為對內(nèi)的SOA平臺沸柔，肯定追求更加高效的通信方式循衰。這類的RPC框架很多，比如阿里的Dubbo褐澎、低調(diào)龐大的Zeroc ICE羹蚣、目前很火的Facebook的thrift等。
- Dubbo：阿里出品乱凿，不過他們家開源的大多是自家棄用的，所以版本迭代幾乎沒用咽弦。有個當(dāng)當(dāng)維護的fork版本Dubbox徒蟆。我只簡單的了解過Dubbo，Dubbo在RPC通信方面主要基于第三方組件的型型，其實他更是個服務(wù)治理框架段审，類似于SpringCloud，整體更側(cè)重分布式集群節(jié)點間的服務(wù)發(fā)現(xiàn)闹蒜、注冊寺枉、負載均衡等服務(wù)協(xié)調(diào)和提高可用性方面，而且他的RPC僅支持Java間的通信绷落，所以我并沒有選用姥闪。
- Zeroc ICE：其實我一開始是想用這個的，因為這篇文章《不得不承認Zeroc Ice是RPC王者完爆Dubbo,Thrift》砌烁，還買了一本書《ZeroC Ice權(quán)威指南》學(xué)習(xí)筐喳，這本書作者好像就是那篇文章的作者催式，不曉得這里有沒有貓膩，反正測試結(jié)果可以參考但不能全信避归∪僭拢看完這本書，感覺ICE太龐大太重梳毙，ICE可以算RPC+zookeeper+docker哺窄，是個RPC到分布式服務(wù)注冊發(fā)現(xiàn)協(xié)調(diào)到項目發(fā)布部署的整體解決方案，這本書200頁左右基本只能做個初級入門账锹，在我實際使用的過程中還是有很多問題要去翻官方文檔才能解決萌业，雖然文檔還是比較全的，但是畢竟Zeroc公司靠基于ICE的咨詢培訓(xùn)賺錢牌废，這里的坑很多咽白，什么默認線程數(shù)只有1啦等等，這么龐大的項目鸟缕，想想以后如果再遇到坑晶框，可能找相關(guān)代碼都要找半天，學(xué)習(xí)成本太高懂从，一旦入坑后遇到致命問題授段，如果不能讀懂源碼就只能放棄整個項目了，不利于以后的項目維護番甩，風(fēng)險太大侵贵，所以我還是及早脫坑了。
- thrift：出自Facebook缘薛，從網(wǎng)上各種測試也都證明他的速度很快窍育，支持非常多種語言。而且很輕量宴胧，很容易集成漱抓，代碼也相對ICE好讀很多，完全滿足我對一個RPC框架的所有需求恕齐。
2. 分布式服務(wù)發(fā)現(xiàn)注冊協(xié)調(diào)
- zookeeper：目前最流行乞娄、最火、最成熟的服務(wù)發(fā)現(xiàn)注冊的組件了显歧，也是我最熟悉的就選用他了仪或，安利一個java的client(curator)。
類似zookeeper這樣的組件還有etcd士骤、Consul范删，以后有機會在嘗試了。
3. 數(shù)據(jù)持久化
- mysql：傳統(tǒng)關(guān)系型數(shù)據(jù)庫拷肌，主要存儲核心的關(guān)系行比較強數(shù)據(jù)瓶逃，經(jīng)常要計算的數(shù)據(jù)束铭，例如用戶名密碼、商品報價厢绝、訂單等數(shù)據(jù)契沫。
- mongodb：經(jīng)典的Nosql代表之一，主要存儲一些擴展和字段不定昔汉，關(guān)聯(lián)性較弱的數(shù)據(jù)懈万，例如商品的詳細規(guī)格各種參數(shù)、用戶個性愛好等靶病。
- Fastdfs：海量小文件存儲会通，fastdfs是個國人寫的小文件存儲文件系統(tǒng)，解決了海量小文件存儲查詢的性能問題娄周。主要用來存儲圖片涕侈、html等靜態(tài)小文件。
- redis：內(nèi)存數(shù)據(jù)庫煤辨，比memcached更強大裳涛，非常適合做session和緩存。而且單個操作是原子性的众辨，所以我還用INCR命令來生成自增ID端三，比如生成訂單號的場景。
- Elasticsearch：相較于lucene鹃彻、sphinx郊闯，es可以像數(shù)據(jù)庫一樣去使用，非常方便易用蛛株，相較于Solr有更好的性能团赁。所以可以把他用在商品搜索這樣的場景。
4. 消息隊列
消息隊列可以做異步處理谨履、解耦欢摄、流量削鋒、日志轉(zhuǎn)發(fā)屉符。
- RocketMQ： 市場上的消息隊列非常多，各種測評也非常多锹引，我們的消息隊列應(yīng)用場景主要是基于發(fā)布訂閱和其他系統(tǒng)解耦矗钟、高峰期堆積消息來做到流量削鋒以及日志轉(zhuǎn)發(fā)到storm做日志分析。因此我們用消息隊列全是實時性要求較低的場景嫌变，所以并不追求實時性吨艇，但我們更在乎消息的順序、消息不丟失腾啥、消息的堆積能力东涡，綜上我們選擇了阿里剛捐給Apache的rocketmq冯吓。
5. 日志分析監(jiān)控
- Storm：較為實時的流式日志分析系統(tǒng)。整個過程是集群將日志和性能數(shù)據(jù)發(fā)送到MQ疮跑，由Storm去MQ pull下來做實時分析再將分析結(jié)果持久化组贺。
6. 持續(xù)集成
- docker：docker非常適合做分布式集群的發(fā)布部署，基于他做持續(xù)集成也是大勢所趨祖娘，有興趣的可以看下我的另兩篇博文《基于docker的持續(xù)集成（一）》失尖、《基于docker的持續(xù)集成（二）》
因此整體架構(gòu)如前面架構(gòu)圖所示，各個組件都相對獨立而且都是比較成熟的組件渐苏，不至于對某個組件依賴太重而被牽制掀潮，以后有更好的組件也方便替換。
7. 開發(fā)語言
其實開發(fā)語言很隨意的琼富，thrift支持多種語言開發(fā)server端仪吧。
-
Java：相較于python、php鞠眉、node等動態(tài)腳本語言薯鼠，Java的開發(fā)效率并不高，但正因為他不是動態(tài)腳本語言凡蚜，而是一個純面向?qū)ο蟮恼Z言人断，還有一個強大的spring框架，加之Java人才遍地都是朝蜘，所以Java絕對是最適合多人合作大型應(yīng)用開發(fā)持久維護的語言恶迈。因此我們暫定以Java為主。其實對于用Spring管理的項目谱醇，applicationContext.xml就是項目最清晰的內(nèi)部組件目錄和項目入口暇仲。篇幅有限，具體代碼就不貼了副渴，就貼一下我們目前主項目的applicationContext.xml奈附。
applicationContext.xml
bibi一下（僅個人觀點）：其實現(xiàn)在Java界新出了一個很火的框架spring boot以及基于他的服務(wù)治理框架spring cloud（類似dubbo）。個人并不是很喜歡spring boot煮剧，雖然spring boot簡化了xml的配置斥滤，減少了開發(fā)代碼，所有的bean注冊都變成了注解或者是默認的約定勉盅，但實際上由于配置分散佑颇，默認約定過反而也導(dǎo)致了代碼可讀性降低，定位BUG困難草娜，不利于項目多人參與維護迭代挑胸。可以說是在提高開發(fā)效率的同時宰闰，降低了維護效率茬贵，而單純只為了提高開發(fā)效率上簿透，何不選用python、php解藻、node等腳本語言呢老充。
歡迎來我的個人博客逛逛: https://blog.52xtg.com
