這個是C10M，還沒有辦法處理的境界，才會到CDN，我稱為「多樣性的處理方式」來處理，也就是用API manager各種不同服務的觀點來切分這一件事，老實講目前其實在scale out做好就夠了。

其實我們有分好幾個步驟，第一個我們談scale up，就是討論到這個機器本身的CPU，最重要的還是語法，也就是要解決資料最終一致性的問題來處理，這個完之後才是scale out，我們就引進很多反向代震技術（音譯）。

雖然我們這邊有準備很多Inbound文件，其實這裡面有很多大量的圖例、範例來說明我們要表達欄位的意思是什麼，我們目前是用word，但我覺得要能夠溝通清楚最重要，要把API描述清楚最重要。以上補充。

第三，要加圖形的描述，讓它畫清楚，讓別人知道物理意義的描述是不是理解、大家的定義是不是一樣的，描述清楚之後再溝通，你們才會站在同一種語言上，並不是給他看Swagger就算了，通常都會說看不懂，我非常同意維志講的，並不是Schema訂好之後就可以溝通了，這個不是可行的事。

第二，要有那個sample的data，要製作給他看。

第一，定義Schema交換格式的時候，真的是不夠，我們跟來源單位討論的時候，其實有很努力準備Inbound文件，要把所有的欄位、描述講清楚。

我補充一下：

Yes。

我補充一下，這整件事我認為是邏輯結構的強迫症，什麼意思呢？資料本身有標準XML、JSON，資料有標準XSD，撈取的語法有標準OData、描述本身也有標準OSD。

第二，機器指跟機器交換的時候，這個描述的結構邏輯很清楚。

另外，剛剛講到Open API的優勢，其實也很有優勢。我們在設計的時候，可以定義API的描述，而API的描述定義清楚，可能用YAML描述，就可以用auto test，就可以testing你的API描述是不是ok的，在這樣抽象性的結構去思考串接你的API。

最後那個推進來的時候，就可以source進來，然後可以選，沒有問題再transform，再放到readies去，所以對品質的提升我覺得很不錯，可以加強這一個優勢。

其實有一些是主動性或者是被動性，假設你定義一個規範，要人家去遵守，人格就是被動性的。主動性是可以加強或補充這個好處在哪裡，比如剛剛所訂的標準Schema，其實在品質的提升很有用的，就可以訂這個質域的名稱及範圍對不對。

因此這三個基本結構，我覺得在定義之前，可能要提醒資料提供單位，必須要這三個資料結構做清楚，不然我相信一上去，你的資料是鄉民感興趣的，你很快就會掛了，這個是我的想法。

甚至有一些更賊，APP就直接連到那邊去了，所以下一步可能還要導入API manager的軟體或工具，像我們家是用Chrome的方式來做這一件事。

第三個是目前最辛苦的，就算交換之後，以PTS來講，我收到鄉民的問題千奇百怪，可能對於資料結構的不清楚，就要去解釋這個就是哪一塊，我覺得光這邊就花非常多的功，並不是寫了網站、放上去，那就沒有問題了，很多APP是會壓身家在你的網站上，就是每天看。

第二個是Data的infra的結構，就是要如何去清洗資料，把共通性的語言、共通性的Schema抽離出來，可以溝通跟資料交換，所謂的標準是為了交換用的，而交換是我跟他之間的語言有共同的語言、concept及定義，這樣才可以交換。

對，就是要討論到這一些，這是infra跟系統的結構。

……C10M的問題。（笑）

其實在資料結構每一層環節都要考慮，包含語法及現在用很多巨量網站加給來支撐這個量，可以一台機器就可以撐住request，這當中要花很多苦功，因此要訂這個還要要求壓測很嚴謹、架構很好，才可以撐得住，不是這麼容易，註明C10K的問題。

第一個是infrastructure，因為要很彈性query那些語法，你的架構如果沒有跟上，你的網站一放上去就會掛，像PTX現在一天是450萬的request，我們開放到現在已經3億多的request。

我想提醒大家的是，剛剛講的資料，而資料撈取方式有一個標準，我們這邊是用OData，我覺得有三個東西是機關建置要考慮的：

一般我也用功了一下，是用JSON或者YAML的格式來描述，這就很容易可以作機器間的溝通。

對。

剛剛講DB Schema的描述以外，我的理解是OpenAPI的部分，其實是在描述這一個資料提供的方式。

第二年當然希望用標準的格式提供給我們，我們的就廢掉，因此就達到資料格式的世界大同，也就是不用來描述這一件事。

這中間會花非常多的苦功來描述，我認為最重要的還是在於領域上的專業，像公共運輸來講，最後抽象到最後，比如時刻表、收費方式，這一些方式訂好之後，可以貫穿到所有的運具，再跟機關來討論，第一年、第二年花了很多苦功，是機關不用動，我們就去寫程式爬資料，以標準的方式提供出來。

我們從最抽象的DB Schema的concept設計到logical及最後digital的Schema都定義清楚，定義清楚之後也要跟機關溝通、協調、討論及磨合，把這個Schema定義清楚，才可以作資料交換，而不是自己悶著頭，然後自己做，就說資料ok了，這是不可能的事。

其實PTX在欄位意思的定義花了很多功夫，因為要貫穿所有公共運輸的DB Schema其實不那麼容易，其實有分好幾個層次來看這個問題。

我的想法是，我們其實是為了交換資料，而資料本身是XML或者是JSON的格式，下一步其實是我們對於資料的描述，而這一個資料描述其實分兩類，一個是告訴我們的作者或者是出版日期，另外一個是指裡面的資料結構的Data Schema欄位的意思。