Abstraksiyon ng Device sa Multi-Account Management System: Apat na Pangunahing Grupo ng Field

Kapag gumagawa ng multi-account management system, kadalasang nagsisimula ang unang bersyon sa interface: gumawa ng listahan ng mga account, mag-attach ng browser profile sa bawat account, at pagkatapos ay tumawag ng mga interface para magsagawa ng mga operasyon. Mukhang sapat ito hanggang sa aktuwal nang tumakbo ang system.

Karaniwang napakadirekta ng unang implementation. Nakaturo ang account A sa profile 001, ang account B sa profile 002, at nakakabit naman ang account C sa isang cloud phone. Lumalabas ang problema sa tatlong lugar: sasabihin ng operations na sira ang isang machine at tatanungin kung puwedeng ilipat ang account A sa cloud phone, pero ang sagot ay baguhin ang database, gawin nang mano-mano, at tanggapin ang panganib; kapag may bagong source ng device at tinanong kung paano ito idaragdag, lumalabas na kailangang i-refactor ang account module; o gustong gamitin ng parehong account ang browser environment sa umaga at cloud phone sa hapon, na halos imposibleng ayusin nang maayos ayon sa oras.

Mukhang magkakahiwalay ang tatlong sitwasyong ito, pero iisa ang ugat: may mga bagay sa account entity na hindi naman talaga dapat naroon. Ang kasalukuyang device na ginagamit sa pag-login, mga dating nagamit na device, fingerprint parameters, at egress address ay lahat nakaimbak sa account. Kaya ang pagpapalit ng device ay nagiging katumbas ng pagbabago sa account, at isang pagbabago lang ay nakaaapekto sa buong system.

Gawing hiwalay na uri ng object ang device

Kapag pinaghiwalay na, dapat many-to-many ang relasyon ng mga account at device. Hindi nag-iimbak ng fingerprint ang account; itinatala lang nito kung saang device ito kasalukuyang naka-bind. Dapat atomic operation ang pagpapalit ng device, dapat nasa hiwalay na table ang history ng bindings, at bawat device ay dapat may natatanging identifier na siyang tanging identifier na ginagamit sa labas, habang puwedeng makita ang status nito nang real time.

Hindi ito ginagawa para lang gumanda ang modelo. Binabawasan nito ang distansiya sa pagitan ng adjustment na gustong gawin ng operations at code change na kailangang gawin ng development, at lumalaki ang distansiyang iyon habang dumarami ang device.

Apat na grupo ng field na dapat malinaw sa abstraction layer

Ang device abstraction na kayang mag-scale ay kailangan lang sumagot sa apat na bagay sa labas.

• Environment ID: natatangi at stable. Sa ID na ito lang dapat tumukoy ang upper layers sa environment; hindi dapat ilabas ang internal numbers, container names, at process IDs
• Egress binding: aling network egress ang ginagamit ng environment at kung magkakatugma bilang isang set ang kaugnay na time zone, language, at DNS. Kapag hiwalay ang abstraction ng egress, puwede itong palitan nang hindi binabago ang environment mismo
• Status: ginagawa pa, handang simulan, tumatakbo, ginagamit ng task, abnormal, naghihintay ma-reclaim. Kung walang status model, walang maayos na batayan para sa pooling at reclamation
• Lifecycle: sino ang nagti-trigger ng creation, startup, occupation, release, at reclamation; ano ang mangyayari kapag nag-time out ang task; at sino ang tatapos ng cleanup kapag nagkaaberya ang environment

Madalas pagsamahin sa iisang field ang status at lifecycle. Ito ang pinakamadaling paraan pero siya ring pinakamahal. Sinasagot ng status kung ano ang kalagayan ngayon; sinasagot ng lifecycle kung sino ang puwedeng kumilos dito sa susunod. Sa production, halos palaging sa ikalawa lumalabas ang totoong problema: nag-crash ang task at walang nag-release ng environment, o na-reclaim ang environment habang tumatakbo pa at sa susunod na startup lang malalamang nagbago na ang egress.

Kapag mali ang abstraksiyon, sa pag-scale lalabas ang gastos

Sa sampung environment, maaaring walang makitang problema. Kapag umabot na sa dose-dosenang o daan-daan, sabay-sabay itong lalabas:

• Ang pagdagdag ng bagong uri ng device ay nangangailangan ng pagbabago sa account module, kaya lumalawak ang regression scope mula device layer hanggang account layer
• Ang pagpapalit ng device ay nangangailangan ng database change, kaya natatakot galawin ito ng operations at unti-unting nagiging developers lang ang kayang mag-maintain ng system
• Kung walang status at occupancy records, hindi nare-reclaim ang mga environment na naiwan pagkatapos ng abnormal exit at dumarami ang zombie environments
• Ang tasks, content, at automation sa upper layers ay nakabatay sa one-to-one na relasyon ng account at device, kaya kapag binago ito ay kailangang ulitin ang buong chain

Malaki ang pagkakaiba ng implementation ng mga device mula sa iba't ibang source: magkaiba ang interfaces na ginagamit ng local browser environments at cloud phones. Ang papel ng abstraction layer ay ilagay silang lahat sa likod ng iisang set ng interfaces. Para magdagdag ng bagong uri ng device, sapat na dapat ang isang adapter na nagpapatupad ng start, stop, at status query; hindi na kailangang baguhin ang upper-layer logic. May simple ring praktikal na test: kapag nagdagdag ng device type, nasa iisang file lang ba ang code na kailangang baguhin?

Sa unang yugto, mas kaunti ang mas mabuti

Kapag malinaw na ang technical model, mas natural nang mabubuo ang interface. Ayusin ang menu ayon sa business objects, na may magkakahiwalay na bahagi para sa accounts, tasks, at devices, sa halip na configuration, parameters, at logs. Dapat pinakakita ang status at exceptions, dahil ang hinahanap ng user ay kung may problema, hindi kung ilang records ang mayroon.

Sa functionality, sapat na sa unang yugto ang device list, pagdagdag ng device, at isang minimal na end-to-end task flow. Paliitin ang menu hangga't maaari, patakbuhin muna nang buo ang isang bagay, at ipagpaliban ang hindi pa kailangan.

Kung ayaw mong gumawa ng environment isolation mula sa simula, puwede ring gumamit ng mga handa nang capability. Nagbibigay ang PurpleMark ng independent environments at egress binding, at sumusuporta sa batch creation ayon sa group at status queries. Kailangan na lang ipatupad sa upper layer ang templates, occupancy, at task scheduling para manatiling nakatuon sa business logic ang engineering effort.

Ang tunay na complexity ng multi-account system ay wala sa dami ng account kundi sa pamamahala ng lifecycle ng device. Unahin ang pagtingin sa device bilang resource na may identity, egress, status, at lifecycle para hindi kailangang gibain at buuing muli ang upper-layer features sa bawat bagong dagdag.