初载于spectredev.xyz，复载于此，以飨Dev.to社群.
择于独体、模块独体与微服务之间乎？此诚初创公司所需之坦率、主观之框架也。勿效Netflix。
尔之架构择，当非因Netflix或Uber之所为而动。当因尔今所处，尔之众之大小，尔之交通之繁简，尔之部署之成熟，及尔之跑道而动。独体与微服务之辩，于尔之境，实有真解。然非诸文所予之解也.
此乃吾侪助初创与成长之公司作此抉择时所循之纲。
众团队何以初起即误
吾所常见之谬：创者闻 Airbnb 或 Grab 自巨构迁至微服务，遂决意自始即建微服务，以为此乃规模之象。
非也。此乃 规模之后 之象。其间有别。
彼诸公司崩其巨构，则数百工师，成备之CI/CD管道，专司之平台团队，历岁而熟其域界之经。非始新也。乃解成长所生之题，非预或永不至之患。
未得市场契合，先行微服务，乃耗尽工力于基建而非产品之速途。吾等亲见其事。睹之痛心疾首。
巨石架构：非议之不当
巨石非恶构也，乃发端之始。至若诚心之众，至十至十五匠人，专攻一物，则此乃正途。
古之单体应用，凡应用之码，皆居一可部署之单元。一码本，一库，一部署之脉。其利甚真，而人常轻之。
初时发展之速，确然迅疾。服务间无网络迟滞，无分布式交易之繁复，无服务发现之冗余。可一气呵成重构全代码。调试直截，盖因万物皆运行于单进程之中。
患生于后。及众手渐众，则文籍愈艰于涉。诸部始相侵伐，事功交杂。布署之役，滞涩而险，盖每变必迁诸事。是时也，构架反为敌，非为助矣。
知众已逾巨构之实，非在通流之多，而在众隙之生，布署之苦也。
如何构建一个可从百人扩展至千万用户的后端系统如何扩展初创企业后端)
模块化单体：鲜有人提及之选择
逆直觉之见：多数自谓需微服务之初创企业，模块化单体实为更优之选。
模塊化單體，猶為單一部署之單元，然內部刻意構為獨立模塊，各具明確界線，自有數據之權，並嚴定模塊相交互之規。思之，猶單體部署模型內之微服務之規也。
其实之效：得微服务之架构明晰，而免运营之烦。可强使团队之所属于模块。可速行而弗损无关之系统部分。及至终决欲析一服务，则模块之界使之为外科之手术，而非痛楚之纠结。
Shopify数年运行单体应用，其将之模块化所做之工，可谓当今工程界诚实之故事。非炫丽之务，惟实效尔。
模块化之单体架构，乃微服务之基石。先立规矩，后析服务，待其运筹有据，方可行之。
微服务：何时方显其义
微服务乃特定情境之适解。诸条件皆须满足，非一即可。
汝之团队甚众，众部各需独立部署之期。系统之中，部分差异极大，譬如实时通知之务，每秒可骤增百万事件，而发票之务仅日处理数百请求。平台工程之力足以运行容器编排、服务织网、分布式追踪及多务值班之轮。汝之领域界限明晰，盖因经营此系统久矣，知其所在。
若有所缺，微服务将滞汝行。
运筹之域，实有其物。于分布式之系，今需调试网络之割裂，应处偏败之虞，理顺界间之架构迁徙，协调多库之部署。此皆可解之题。合而观之，需一团队有清思以解之。
SpectreDev之客户，某A轮融资之金融科技公司，尝以六工程师之众，欲迁微服务。十八月矣，得八服务，其三不能独立部署，盖因共享状态未明。是团队所费时日，多在基础设施之变故，而非功能之开发。吾等乃费三月，将其化简为模块式单体，再逐步重建抽取。此中反讽，非众人不知也。
决策框架
以此为始。此乃主观之见，本意如此。
若：产品市场契合未至，团队工程师不足八人，且主要制约乃开发之速，则建单体应用。
若：重构为模块化单体应用。尔已得产品市场之契合，团队渐增，始感共享代码库之组织摩擦，然平台尚未成熟，不能行分布式系统之务.
若欲自模块化单体中析出服务，则需： 某模块之部署节奏、伸缩模式、团队归属皆异，足以证其运营之费。先治一务，善之，再决次务。
察其未列者：曰"盖吾辈期有千万用户之期"。此非架构之决也，乃空想耳。当为今之境与次第之增盛而构，非为远不可及之顶而设。
尤以印尼诸公司为甚，尚有才者之可虑。习分布式系统之工，如 Kubernetes、服务织网、分布式追踪者，于雅加达较之旧金山，其市甚寡。模块化之独体，使今之众工得安，其价胜于微服务之构，因其致聘之困，非可解也。
事例实相：区域电商初创当思此道
想一区域电商平台，于印尼、马来西亚、菲律宾间营运，用户活跃者五万至二十万，且日增其数。
夫其规模若此，则架构之宜，殆为模块式独体。宜设隔离明晰之模块，以治产品目录、订单管理、支付（尤需虑及区域支付法如GoPay、OVO、GrabPay各具集成之理）、及物流追踪之事。
彼等尚无需独立部署。然构为模块，则俟至用户逾二百万，且支付模块于双十一急售之际频遭冲击，便可将其抽离为独立服务，且已有明晰之API契约已然备妥。根基已奠。
欲为诸域建备选之微服务，若用户达五万，则需增月余之基建之功，未尝验其产品于三市皆有效也。
常见问题
问：可始以单体，后迁至微服务，而勿重改乎？
A：然此实乃所谋迁化之道也。其要在于自初即维净其模块之界于独体之内。若尔已构制井然之模体独体，则析出一服务，当明定其API之界（盖已存为模块之介），设其部署之基，渐移其流。此犹为劳甚，然非重撰也。缠结之依存所成之“大爆”独体，乃需痛改之重撰者。
Q: 众多少人，方当思迁微服务乎？
A：团队之众非唯一变数，然有粗略之法则：凡工程师逾十五二十而共治一码库，且部署之滞可量，则当启此议。至要之验，乃察系统一隅之变，可无伤他隅否？若其答常为“不可”，致损己甚，则此乃关键。
Q: 微服务较之单体架构，其安全是否更为艰难？
A：难易有别，未必更艰。独体之构，攻面虽敛，然一损可及全局。微服务之制，攻面虽广，然需谨固服务间之通（mTLS、服务账户、网络策略）。安危之态，全在所施。二者之构，本无定安。
Q: 服务器无状态之谓，为第四之选乎？
A：无服务器函数可作诸般架构之良式，然非可代之架构也。或置诸模块式单体之内（如异步事件处理之例），或置诸微服务系统之内。无服务器自生其繁，关乎冷启动、无状态设计及供应商锁定，此多团队所轻估。于多数初创公司，此乃工具，非策略也。
吾乃非技之人，欲知吾等之技团所荐之架构，当如何审之？
A：请其详述权衡之故，非惟择其一端。良工善言，能道其所弃，非徒陈其得。若微服务之议，不直言其运维之费、分布之繁、及吾辈之能，是可警也。至若汝之阶，最佳之构，宜略带平淡。炫目之选，多耗资财。
至当之架构者，使众匠得成其事，持守其信，随商贾之变而迁也。此非微服务也，非尔等多见之众。盖结构精良之独体，或模块化独体也，予汝以纪律，俾得渐臻分布之境，俟实有明证而始行之。
若君处此境，此等抉择已成现实，无论君在初创之途或遭遇系统之限，此即吾辈于SpectreDev与客商共商之务也。