iT邦幫忙

0

假設一個電商系統(網站),要給多個業主使用,如何有效「管理」與「更新」?

這對我來說算是新世界,有點像 shopline(?
我很好奇一些作法,不知道有沒有大大願意分享的,或是知道怎麼做的

像 shopline 是程式碼都在他那,你只要申請付錢就可以使用
那他要怎麼解決網站語言和跨國伺服器的問題?
因為當然是離TA地區越近越好的伺服器據點吧?
加上申請人如果要客製化呢?
總不可能有多少業主就多少份程式碼吧?裡面有 function 需要更新怎麼辦?

我這邊有一個想像性的問題
假設有一套電商網站(包含 php, css, js, html...)
想要做到多個業主使用,前提是業主都有自己的伺服器
但是這一套程式碼是用複製嗎?到業主伺服器
問題來了
在同一份的情況下,要怎麼針對這些業主做數據庫連接、網域、金流甚至語言的客製化?
如果有 config 檔案是所有業主的數據,根據該伺服器綁定的域名做判斷
那這樣這份 config 不就大家都看得到了
這只是我的想像
只是我好奇到底是怎麼管理這些程式碼才是對的?
加上如果有共用的程式碼可以使用呢?是不是應該提出來?
假設某一個功能是A業主要的
但是BCDEF業主不要這功能,這怎麼解?
你還是用同一套程式碼

1
scorpionx
iT邦新手 5 級 ‧ 2019-05-15 23:35:43
最佳解答

我的做法目前是這樣

1.site-config部份通通寫入到資料庫內 (參考Wordpress MultiSite)
2.網站的功能開放跟不開放,也是透過 ACL+config來設定 (參考Wordpress MultiSite)
3.業主如果有提出申請要自架私有雲,更新的部份我在系統上有留一隻 php 做 curl去擷取公有雲的版本是不是跟私有雲的版本有差異,由業主自行決定要不要更新 (可以利用RSS等,參考Wordpress的做法),當然,還得去做版本差異的各種一鍵升級的script (還是建議參考wordpress/Joomla這類的CMS的做法)
4.客制化的程式都用Composer載入,只要Framework記得 auto_load就好,framework的routing也要實做Dynamic routing (客制化的模組通通都從db做好設定跟管理)
5.多語系改以前端JS做 string_replace來完成 (參考各大訂房網站系統的實作方式),預設語系字典也可以在config裡面寫好

總而言之,既然只想要做單一版本研發,又不想失去需要客制化的客戶,就把所有客制化當成third-party套件來做,但是自己的系統還得在設計時做一個 default_value 的概念,以Laravel的例子來說,env('MAIL_DRIVER', 'smtp') 預設值為 smtp,但可以透過 .env file去設定 'MAIL_DRIVER' = mailgun去覆蓋,然後不同業主客戶在各自的.env file就有不同的 MAIL_DRIVER 的value,更新的時候只要避開 .env file被更新到就可以了 (乾脆把.env file轉到DB內更好)
shopline在公有雲上的實作方式我是不知道,但是如果說以Laravel來實做的話,我會把laravel Project透過 apache實做multi-site share one code,這個方式請參考 wordpress multisite的方式,有各種技巧可以達到

但上面提到的做法需要把工作切得很細,某種程度上投資成本還滿大的,RD的耐性是要很足夠的

以上,小弟淺見

小松菜奈 iT邦研究生 3 級 ‧ 2019-05-19 15:19:17 檢舉

想問一下語言問題
語言我可以透過網站結尾 ?lang=??? GET去切換對應的文字檔
但這樣是否無法收錄到搜尋引擎?
因為假設分美國跟台灣
假設在美國搜尋時,是如何自動換成已經翻譯過後的網站標題?
比如說 Apple 官網在台灣搜尋 apple 標題是 Apple 台灣
在美國是 Apple 而已
這是怎麼做到?

scorpionx iT邦新手 5 級 ‧ 2019-05-20 11:46:23 檢舉

SEO有SEO的玩法,例如你可以先參考這一篇
https://support.google.com/webmasters/answer/182192?hl=zh-Hant&ref_topic=2370587

早期到現在的多語系網站都有不同的玩法,例如從Doamin開始的 en.example.com或是zh-tw.example.com,若無Doamin管理權的,像是使用Free DNS(no-ip這類的),大家的玩法則是 myaccount.no-ip.info/en/, myaccount.no-ip.info/zh/ ,當然還有你提到的 myaccount.no-ip.info/?lang=en 這種做法,各有利弊以及本身在多語系的需求上,客戶想要的跟預算能讓你做到什麼程度

在?lang=en這的地方其實有小技巧,利用 http daemon的rewrite就可以解決,在framework上的routing進入middleware/controller把view輸出前,就可以判斷lang傳來的值,然後把字典檔輸出給view去處理,一樣可以解決 SEO的問題

當然,有些人很討厭切換與語系就要跳頁的問題,這個就有三四種解決方法,其中一種事前端JS AJAX拉字典檔回來做String Replace,這個確實有國際型網站是這樣搞的例如 thebookingbutton,另外一種一樣還是跳頁,但是你得去把當下客戶的購物車等所在位置紀錄下來,在切換lang redirect回去時想辦法把東西補回去 例如 booking.com的網站就是一種做法

最後,很多open source的cms在這一方面其實都有很成熟的解決方案,多研究一下其實就會發現優缺點,有許自己還有能力改一改就變成百分之百的解決方案

scorpionx iT邦新手 5 級 ‧ 2019-05-20 13:10:07 檢舉

補充一下,如果有機會遇到用MVC Framework網站在線更新或是小崩潰時
有機會看到以下情況

9
raytracy
iT邦大神 1 級 ‧ 2019-05-15 09:10:22

這是很常見的做法, 通常稱做: Multi-tenant, Multi-Company, Multi-Vendor.....面對多用戶的大型應用系統都有這種能力, 不只有電商, 還有: ERP, CRM, Email, 網路空間.....等等...

別的不說, 一些跨國集團裡面, 自己就有 2,30 家子公司, 如果是集團作帳, 難道要各子公司各買一套 ERP, 再把所有報表輸出後, 送到集團總部, 叫總管理處自己匯總嗎? 集團沒這麼笨, 只要買一套可支援多公司別的 ERP, 就可以讓所有子公司都上來使用屬於它們自己的功能....

架構規劃得好的, 只需要一套程式, 就可以給多用戶使用; 功能啟閉都是在資料庫裡面註記, A 客戶可以用: 1,3,5,6,7,8 功能, B 客戶可以用 4,5,7,8,9 功能, 畫面出現每一張選單之前, 後台程式要先跟據資料庫的註記, 組出適合這個客戶的畫面, 再顯示出來.

所以全部的顯示畫面都是經過運算之後, 即時動態產生的, 不是一隻隻寫死的網頁檔案, 這樣才能根據客戶的類別, 即時顯示不同的畫面...

當然, 如果沒有這種規劃能力的話, 那也可以很原始的: 一家客戶給一套專屬原始碼, 然後根據他的需求去客製他專屬的原始碼; 不過, 這樣管理上百家各自不同的原始碼, 就已經天昏地暗了, 想要管理上萬家客戶, 會是一場災難....

小松菜奈 iT邦研究生 3 級 ‧ 2019-05-15 21:51:00 檢舉

我的想像是一套電商是已經確定完成的版本(大致上)可以將此套直接給業主使用(當然就是複製一份過去),基本上不給客製這樣(但這樣也很怪),但可以客製的話我就必須要有好幾份相同的程式碼⋯⋯這樣更新也不方便,真的傷腦筋

3
dragonH
iT邦大師 1 級 ‧ 2019-05-15 10:21:28

網站語言問題?

i18n

跨國伺服器問題?

CDN ?

申請人如果要客製化呢?

就客製化, [shopline](https://shopline.tw/faq/features)也有提供

總不可能有多少業主就多少份程式碼吧?

可能, 看你的規劃, 而且你又有業主都有自己的伺服器的前提下

裡面有 function 需要更新怎麼辦?

看你是代管Server還是啥的, 不同情況不同做法

業主都有自己的伺服器,在同一份的情況下,要怎麼針對這些業主做數據庫連接、網域、金流甚至語言的客製化?

如果業主都有自己的伺服器了, 就照一般流程做

有 config 檔案是所有業主的數據,根據該伺服器綁定的域名做判斷
那這樣這份 config 不就大家都看得到了

為什麼這東西會出現在某個業主自己的伺服器

只是我好奇到底是怎麼管理這些程式碼才是對的

你要先確定你網站到底是提供"服務"給客戶(登入, 權限控管)

還是就是幫客戶寫他專屬的網站(類似外包)

假設某一個功能是A業主要的, 但是BCDEF業主不要這功能,這怎麼解

1.提供服務的網站 => 權限控管

2.幫客戶寫他專屬的網站 => production的時候就不應該包進去

總結

shopline看起來是走提供服務, 代管Server的方式

所以我想他應該是用權限來控制每個客戶能使用的功能等

如果你是想寫這種網站

那你一開始的出發點就不太對

你不只是設計一個電商網站

而是設計一個管理電商網站的網站

除了商店功能的實現

你還需要管理這些商店的功能實作

這種應該也不會出現客戶有自己Server的情況

像樓上大神說的

規劃很重要

以上拙見
看更多先前的回應...收起先前的回應...
小松菜奈 iT邦研究生 3 級 ‧ 2019-05-15 14:06:31 檢舉

config 檔不是需要丟到程式裡面讀取嗎?
包括測試連測試資料表 正式連正式的
根據網域判斷

dragonH iT邦大師 1 級 ‧ 2019-05-15 14:40:30 檢舉

但你的前提是 "業主都有自己的伺服器" 沒錯吧

那你這所謂的 config 檔

裡面應該也只會有這個業主的東西吧

小松菜奈 iT邦研究生 3 級 ‧ 2019-05-15 14:47:47 檢舉

但業主“都有自己的伺服器”這作法好嗎?
這樣程式碼更新的時候是不是蛋疼

dragonH iT邦大師 1 級 ‧ 2019-05-15 15:04:10 檢舉

當然不太好呀

樓上樓下都有說這樣做的缺點了

你舉的例子 shopline

看起來也不是這樣做的

所以還是取決你的產品的定位

到底是類似 外包 還是賣 服務 的

小松菜奈 iT邦研究生 3 級 ‧ 2019-05-15 15:18:35 檢舉

那我認為會是服務⋯
只是光是跨國語言,就應該要考慮到伺服器了
所以也就是說原始碼還是會需要丟到別的伺服器去

dragonH iT邦大師 1 級 ‧ 2019-05-15 16:03:39 檢舉

放心吧

多語言絕對不會是你會遇到的最困難的問題

因為有一堆套件可以用

codepen

小松菜奈 iT邦研究生 3 級 ‧ 2019-05-15 17:41:31 檢舉

我發現我們的性質會是偏向外包⋯
就很像是一套系統賣給你
但是我們這邊如果有更新,你那邊也可以使用到更新

newkevin iT邦高手 1 級 ‧ 2019-05-21 06:50:35 檢舉

套件更新區 客制區 管理
1.丟給客戶自己處理要不要更新
(客戶自行判斷)
2.程式比對 或人工比對
更新會不會影響那些客制區功能
A 完全不會 (建議或強制更新)
B 會影響 加個客戶版本控管
(看公司給客戶免費更新 或收費更新)

3
浩瀚星空
iT邦大師 1 級 ‧ 2019-05-15 11:43:10

我不說比較專業性的話,就單純白話的做法讓你知道一下。
一般來說,這區分如下的做法

1.同主機區分法:
你的程式碼就只有在一個地方,但用域名或是特規key的方式。利用區分資料庫或是其它特規處理的方式來做分開或共用使用。這樣子的做法則是需要你的商家都得到你的主機上。商家只能申請使用權。
好處是程式更新是所有的商家一起更新。缺點就是功能的部份比較無法自定義化。雖然可以用類似插件或是模組的方式來決定商家需要的功能有哪些。
現在有很多線上的erp系統大多會這樣做,你只是租用其服務。對商家而言是可以省下買主機的架構。但資料的安全性就有很大的考量因素存在。

2.中央server連動處理:
一般這種做法是會區分伺服端及客戶端。客戶端的程式碼可以提供下載給客戶安裝使用。
可是客戶端的部份連接還是得利用server端來做連動處理。這樣的好處是能保護你的程式碼不會全給客戶,並且在程式更新時可自動化的連動更新。依購物車而言,像是一些信用卡的機制則可利用你的server來做服務,不需要透過客戶端的server。
不過目前已經很少看到這樣的模式。大多數都是應用在多分公司的情況下。很少在應用程式中看到這種模式。大多數而言,只是為了公司及分公司的情況下才做這樣的規劃。這可以確保資料數據的統一化及個別設定規劃。目前比較常看到的設計還是屬於erp居多。

3.程式更新版本處理
跟第2點的做法有點類同。但性質不太一樣。程式碼是只有客戶端獨立性的東西。server這邊只有單純的程式版本控管的程式。不負責其它追加的服務。目前很多論壇、blog、購物車..等單機式的應用程式都是用此方式處理。客戶可以在後台看到目前的版本到哪邊,自已決定是否需要下載更新。
我們的程式就是單純的修改好之後放到server,並修正新的版本號提供給客戶自行處理。
這種方式是目前比較常見的方式。當然其缺點就是程式碼是要直接給客戶的。說好聽一點可以讓客戶做二次開發處理。說難聽一點,就是一種服務性買斷的方式。
絕大多數而言,這一類的產品,大多數來說幾乎都沒技術的支援。(有些可以付費尋求技術支援)
有些還有區分更新權跟使用權。也就是說你依然可以在未來更新你的版本,但客戶在更新期限超過的情況下,就得另外再付費。(免費的就除外了)

大約目前的性質是如此。我早前設計的購物車是有第1點做法跟第3點做法。

小松菜奈 iT邦研究生 3 級 ‧ 2019-05-15 21:51:30 檢舉

如果是你會怎麼做呢?

0
idoncys
iT邦新手 3 級 ‧ 2019-05-18 15:01:19

假設某一個功能是A業主要的,但是BCDEF業主不要這功能,這怎麼解?你還是用同一套程式碼....

我們都接不同性質的案子,用同一套程式碼,且都放在客戶主機,客戶的所有操作介面與邏輯運作都放在他們的私有雲資料庫.
個人的看法是每個案子的需求可能會相似但都不會一樣,用同一套流程與邏輯不可能應付所有差異的需求,如果客戶有使用,也都是用適應與將就的想法去使用.

小松菜奈 iT邦研究生 3 級 ‧ 2019-05-19 13:07:41 檢舉

也就是說是靠業主個人的資料庫去控制

idoncys iT邦新手 3 級 ‧ 2019-05-21 17:30:00 檢舉

我的看法是因應客戶需求寫程式碼,越寫就會越多,越多就越失控,雖然我都是做資料管理方面的,但意思應該差不多.
所以我都會努力把程式碼只寫一次,然後商業邏輯與版面操作設定等都存到客戶資料庫,然後由程式動態去載入處理,之後客戶管理,庫存管理,報價訂單管理等都是用相同程式碼.
商業邏輯與版面操作設定都進入資料庫以後,需求變更就變成在維護表單,而不是寫程式碼,維護工作效率比較高,又可透過資料庫做傳承.

1
小魚
iT邦大師 1 級 ‧ 2019-05-18 16:03:32

其實,
沒有完美的程式,
很多大型程式設計完之後也是一直在改進,
這種東西就是經驗的累積,
其實很多人都是先去大公司打滾,
很多東西也只有大公司才有機會遇到,
有了一定的經驗之後再出來做,
來這裡問大概只能問到概念,
真正的東西還是需要多實作多改進.

小松菜奈 iT邦研究生 3 級 ‧ 2019-05-19 13:09:44 檢舉

我就是寫了電商後踩了很多坑,
就像假設網站有三種身份
前端(給使用者
前端後台(給管理員
廠商前端後台(給廠商管理員
光是這三個的 CSS/JS是不是就可以分開寫了
除非是全局的共用檔案就丟到全局

小魚 iT邦大師 1 級 ‧ 2019-05-19 14:29:26 檢舉

那應該算是三個網站吧,
基本上是分開寫的,
不過如果你命名規劃很好,
CSS跟JS要放一起也是可以..

小松菜奈 iT邦研究生 3 級 ‧ 2019-05-19 14:49:48 檢舉

放在一起會有災難,像我現在就是⋯
命名好難

我要發表回答

立即登入回答