操作系統的體系結構是一個開放性的問題。
正如上文所述，操作系統在核心態為應用程序提供公共的服務，那么操作系統在核心態應該提供什么服務、怎樣提供服務？有關這個問題的回答形成了兩種主要的體系結構：大內核和微內核。
大內核系統將操作系統的主要功能模塊都作為一個緊密聯系的整體運行在核心態，從而為應用提供高性能的系統服務。因為各管理模塊之間共享信息，能有效利用相互之間的有效特性，所以具有無可比擬的性能優勢。
但隨着體系結構和應用需求的不斷發展，需要操作系統提供的服務越來越多，而且接口形式越來越復雜，操作系統的設計規模也急劇增長，操作系統也面臨着“軟件危機”困境。為此，操作系統設計人員試圖按照復雜性、時間常數、抽象級別等因素，將操作系統內核分成基本進程管理、虛存、I/O與設備管理、IPC、文件系統等幾個層次，繼而定義層次之間的服務結構，提高操作系統內核設計上的模塊化。但是由於層次之間的交互關系錯綜復雜，定義清晰的層次間接口非常困難，復雜的交互關系也使得層次之間的界限極其模糊。
為解決操作系統的內核代碼難以維護的問題，於是提出了微內核的體系結構。它將內核中最基本的功能（如進程管理等）保留在內核，而將那些不需要在核心態執行的功能移到用戶態執行，從而降低了內核的設計復雜性。而那些移出內核的操作系統代碼根據分層的原則被划分成若干服務程序，它們的執行相互獨立，交互則都借助於微內核進行通信。
微內核結構有效地分離了內核與服務、服務與服務，使得它們之間的接口更加清晰，維護的代價大大降低，各部分可以獨立地優化和演進，從而保證了操作系統的可靠性。
微內核結構的最大問題是性能問題，因為需要頻繁地在核心態和用戶態之間進行切換，操作系統的執行開銷偏大。因此有的操作系統將那些頻繁使用的系統服務又移回內核，從而保證系統性能。但是有相當多的實驗數據表明，體系結構不是引起性能下降的主要因素，體系結構帶來的性能提升足以彌補切換開銷帶來的缺陷。為減少切換開銷，也有人提出將系統服務作為運行庫鏈接到用戶程序的一種解決方案，這樣的體系結構稱為庫操作系統。