如果您已经在Sitecore上工作了至少几年，那么您很可能已经有了自定义MVC解决方案，或者使用过saxa这样的加速器(希望您现在已经摆脱了webforms和XSLT)。该解决方案可能包括自定义组件和集成。这个解决方案甚至可能经历了一两次升级。这个解决方案可能花了好几年的时间。因此，当Sitecore和其他CMS供应商开始兜售“无头”作为未来时，怀疑是你的自然反应。在一切终于开始运转的时候重新开始似乎并不吸引人。
考虑到这一点，当Sitecore和开发社区吹捧无头解决方案的优点(如更快的加载时间、易于部署、减少基础设施成本和更高的灵活性)时，您可能已经不再听了。不听是一个错误。基于虚假困境的错误。保持现有的解决方案，转向无头系统并不一定是一个全有或全无的决定。你可以慢慢地把无头引入到你的解决方案中。
最基本的
当使用Sitecore无头服务时，内容和布局在Sitecore中管理，并使用它的“布局服务”提供给应用程序。这意味着实际的网站不是由Sitecore CD提供服务，而是由渲染主机提供服务。这通常是Node.js或ASP。净的核心。Sitecore提供SDK，帮助将布局服务集成到解决方案中。
如果您正在使用headless构建一个新网站，您可以只使用布局服务将DNS映射到您的渲染主机和Sitecore服务内容和布局细节。如果您有使用MVC或saxa构建的现有Sitecore站点，您可以并排服务它们，不会产生冲突，因为呈现主机只会为一个单独的无头站点提供请求。
让它在一个网站上工作
如果你已经有了一个网站，你可能想要引入新的无头功能，而不需要使用一个单独的域名。使用反向代理可以很容易地解决这个问题。如果您正在使用Azure, Front Door可以轻松处理这个问题。请求来到前门，根据路径，它将请求路由到无头渲染主机或Sitecore CD。
这允许您使用完全支持headless的功能来扩展现有站点。这也是一种缓慢移动现有功能到无头的方式，而不需要执行一个大的包重建。
为了支持这一点，您可能需要复制页眉和页脚组件，尽管它们都可以由支持现有MVC/Sitecore解决方案的相同内容驱动。您可能还需要考虑如何支持在无头解决方案和现有站点之间共享会话数据或经过身份验证的状态。
如果你不在Sitecore 10上呢?
要利用Sitecore无头服务，你应该使用最新版本的Sitecore。但是，如果您的主要解决方案是在Sitecore的旧版本上，并且您还没有准备好升级，那么您仍然可以使用Front Door来管理现有实例和准备好支持无头服务的新实例之间的流量。
请记住，您将需要更多的基础设施和许可来支持这种方法，但如果正在进行升级，这可能允许您在解决方案升级的同时更快地使用新功能，而对许可的影响有限。
如果这是一个长期的解决方案，那么您可能需要解决的一个问题是提供一个统一的站点搜索，从两个实例返回结果。为此，您需要一个统一的索引。虽然您可以尝试让一个Sitecore实例索引另一个实例，但其他解决方案如Coveo或Apache Nutch可以索引呈现的页面，更容易维护。
让它更快
一旦使用headless驱动站点的某些部分，就可以考虑利用Sitecore的体验优势使其运行得更快。使用这种方法，你的布局和内容细节被发布到Sitecore的体验边缘CDN，确保这些细节被边缘缓存到最接近访问者的位置。
使用这种方法，无头应用程序将完全独立于Sitecore内容交付实例。整个应用程序由您的渲染主机和体验边缘提供服务。当XM云发布时，您也将为它做好准备。
结束
Headless提供了真正的好处，并且您不需要等到重新构建整个解决方案才能开始获得这些好处。如果计划得当，像Front Door这样的工具可以很容易地将您的无头功能与标准MVC和saxa解决方案同时提供。
谢谢你的文章!
我们目前正在研究“让它在一个网站上工作”的解决方案，所以很高兴看到你提出了同样的方法。
我可能不完全理解“让它更快”的解决方案。Azure Front Door与CDN(高级层)一起使用是否足够，而不是像你建议的那样将CDN(体验边缘)放在较低的层中?通过这种方式，我们可以节省使用NodeJS的时间，不必重复渲染这些东西。我想这取决于场景/需求。
欢呼,
那是
让它更快，我的意思是让你的渲染主机利用Sitecore的边缘缓存API的布局和内容，而不是必须去CD服务器。如果您试图在Front Door缓存所有内容(甚至是内容页面)，那么在发布时需要某种方法来清除缓存。Experience Edge是自动管理的。