企业官网建设流程全解析

ArcGIS Enterprise的部署，说难不难，说简单也绝对不简单。早年在某个地理信息项目现场，我原以为装个软件而已，照着安装向导一路下一步就行。结果真正动起手来，从裸机到能对外发布服务的完整平台，前后花了三天半，其中踩坑的时间占了一大半。后来复盘才发现，安装本身确实不难，难的是部署前的架构设计、环境规划和那些官网文档里不会明说的细节。

这篇文章把我多次部署ArcGIS Enterprise的完整经验写下来，包括架构选型思路、环境准备清单、各组件安装顺序、常见问题排查，以及部署完之后的运维和扩展要点。如果你是第一次接触这个平台的交付人员、GIS运维或项目集成开发，看完应该能避开绝大多数我踩过的坑。

1. 部署前需要先弄明白的架构问题

很多人一上来就想装软件，这是最大的误区。ArcGIS Enterprise不是单个程序，而是一套由多个组件协同工作的平台，装错顺序、理解错各组件的关系，后面一定会返工。

1.1 四个核心组件各管什么事

ArcGIS Enterprise从功能上拆解，核心由四个部分组成：

• Portal for ArcGIS：整个平台的门户，相当于“前台接待”。用户通过浏览器访问门户来浏览地图、创建场景、管理成员和内容。它也负责托管服务的生命周期管理。
• ArcGIS GIS Server：真正的“后厨”，负责处理所有GIS计算任务，包括地图渲染、空间分析、要素访问、GP服务执行。它承载所有托管服务和处理服务，没有它Portal就是一个空壳。
• ArcGIS Data Store：专用数据仓库，负责存储Portal创建的服务所依赖的数据。它内部细分为关系型存储、切片缓存存储、时空大数据存储三种类型。
• ArcGIS Web Adaptor：部署在Web服务器（Tomcat或IIS）上的一个适配组件，相当于“门卫”。它把外部HTTP请求按照URL路径转发到Portal或GIS Server，同时负责负载均衡和统一入口。

理解这个逻辑非常关键：用户从Web Adaptor进入，Web Adaptor把访问门户的请求交给Portal，Portal安排GIS Server干活，GIS Server从Data Store读写数据。四者串成一条完整链路，谁都不能缺。

1.2 三种典型部署形态怎么选：单机、双机、分布式

很多教程都会给出一堆部署拓扑图，但落到实际上，工作里最常见的其实就是三种形态。

单机部署：把全部四个组件装在同一台物理机或虚拟机上。适合开发测试、演示环境、小团队试用。优点就是链路简单、占用资源少；缺点是单点故障，门户挂了一切都挂。我平时做技术验证就习惯用这种，省心。

双机部署：两台服务器，一台装GIS Server，另一台装Portal加Data Store。这是小规模生产环境最常见的做法，GIS渲染计算和数据存储分离，性能比单机好很多，故障面也缩小了一半。

分布式多机部署：所有组件各自独立部署在一台甚至多台服务器上，GIS Server可以横向扩展出多个节点组成站点，Data Store可以配置主备复制，Portal也可以做高可用。这种形态服务于在线用户量大、数据量级在TB以上、业务不允许中断的生产系统。代价是硬件投入翻倍，配置复杂度指数级上升。

到底选哪种，我有几个判断依据可以参考：

• 在线用户数在50人以内、数据量不上TB、能接受部分时段停机：双机部署足够；
• 用户上百、数据量达到TB、要求7×24小时服务：直接走分布式加高可用；
• 只是一次性项目演示、POC测试或者内部试运行：单机就够了，别浪费资源。

另外必须强调一个原则：架构设计必须在部署之前完成，而不是装好之后再改。组件之间一旦创建站点、配置了存储路径和证书，后期想从双机扩成多机，牵扯到迁移和重新注册，工作量非常大。我第一次部署就是没想清楚，先用单机装了一遍，后来项目规模上来了，几乎推倒重来。

2. 环境准备阶段最容易忽略的四个细节

如果你问我在ArcGIS Enterprise部署项目中最费时间的是什么，我几乎可以不假思索地回答：不是装软件，而是环境准备。安装包本身几分钟就能装完，但前置环境的折腾，经常以天为单位计算。

2.1 服务器硬件与存储规划

先说不谈具体型号，只谈我实践下来的硬性要求：

• CPU：GIS Server是计算密集型组件，核心数越多越好，建议至少8核。Portal和Data Store对CPU要求相对低一些，4核以上即可。
• 内存：单机环境下16GB起步，分布式环境下Portal、Server、Data Store各自8GB以上，Data Store的内存和数据库缓存强相关，空间数据量大时16GB并不算多。
• 磁盘：系统盘和数据盘一定要分开。Data Store的数据目录最怕和系统盘挤在一起，一旦C盘（或Linux根分区）被日志占满，数据存储服务会当场罢工。我见过同事因为没分盘，最后只能迁移Data Store，折腾了一整宿。

还有一个小细节：ArcGIS Data Store底层的空间数据存储对磁盘延迟比较敏感，有条件就上SSD。尤其是切片缓存存储，如果磁盘性能跟不上，地图发布和切片生成会慢到让你怀疑人生。

2.2 端口规划与防火墙放通清单

ArcGIS Enterprise各组件之间的通信依赖特定端口，部署前必须把端口清单理清楚。这也是最容易出问题的地方——组件在各自机器上装好了，但互相访问不通，最后查半天，发现是防火墙没放通。

我在实际项目中使用的端口清单大致如下：

另外还有两种部署时的变体：同一台机器上装多个ArcGIS GIS Server站点实例时，端口会加上偏移量，比如7443变成7443+偏移；Data Store默认端口范围是29000-29004左右，具体以实际配置为准。我一般不会死记固定值，部署时在安装向导里看清楚填写的端口号，再在防火墙里放通对应的端口段。

提示：部署前先做端口连通性测试，不要等装完了再排查。Windows环境用Test-NetConnection，Linux环境用nc或telnet都行。

2.3 域名、证书与主机名，一步到位少返工

这一节是我最想强调的。ArcGIS Enterprise对域名和HTTPS证书的依赖程度远超大多数人的预期。

先说主机名。服务器装好后，主机名尽量不要改。组件创建站点时会把机器名写进配置里，后期改了主机名，服务状态会异常，甚至Web Adaptor会话失效。部署前就规划好每台机器的主机名，用起名规则统一的命名，比随便给个随机主机名要省事得多。

再说域名。正式生产环境一定要规划一个对外使用的域名，比如https://gis.xxx.com，而不是直接用IP地址访问。Portal创建站点时填写的访问地址会写入很多重定向逻辑，如果前期填IP，后来换域名，所有服务URL都要改一遍。而且因为浏览器安全策略的限制，很多功能只有HTTPS域名下才能完整使用。

证书建议直接上通配符证书。一个*.xxx.com的通配符证书，可以同时覆盖门户、GIS服务器、Web Adaptor的多个子域名或路径，省去维护多个证书的麻烦。自签名证书不是不能用，但开发测试可以，生产环境强制建议CA签发的证书，否则浏览器拦截、移动端App无法访问、Portal与Server之间相互调用时报HTTPS错误，这些问题会轮番轰炸你。

2.4 运行账号与共享目录

ArcGIS Enterprise在Windows环境下，服务默认以特定运行账号启动。开发环境用本地账号没问题，但生产环境建议使用专门的域账号，而且这个账号需要对该服务器上有读写权限的目标目录具备访问能力。

同样的坑在共享目录上更是常见。为了支持高可用和故障切换，GIS Server的配置存储、内容目录，以及Portal的配置存储和内容目录，通常要放在共享存储上。很多项目在部署时图省事，全放本地磁盘。等后期要做高可用、加节点时才发现，共享目录没有提前准备好，迁移起来相当痛苦。

目录规划我习惯分开处理：

• GIS Server内容目录：存放服务定义、地图文档、GP工具等，需要共享；
• GIS Server配置存储：存放站点配置信息，需要共享；
• Portal内容目录：存放门户成员上传的内容，需要共享；
• Data Store数据目录：存放空间数据本身，Data Store高可用时同样需要共享。

共享目录权限也是个容易踩坑的点：运行账号必须对共享目录拥有完全控制权。有些单位安全策略严格，服务账号没有写共享目录的权限，结果Server站点创建到一半就报错，排查下来其实权限问题。

3. 实操：按正确顺序一步步装通一套企业版

环境准备好了，终于可以进入正题。ArcGIS Enterprise组件安装顺序是有讲究的，我一般按“Web Adaptor → GIS Server → Data Store → Portal → 统一入口联调”的顺序走，这也和官方建议的部署路径基本一致。

3.1 先装宿主机环境与Web Adaptor

Web Adaptor需要寄生在Web服务器容器里，Windows环境通常用IIS，Linux环境通常用Tomcat。IIS版本、Java环境版本这些基础软件要先准备好，再装Web Adaptor本体。

从安装包的角度说，Web Adaptor分为Windows版和Java版，Windows版挂IIS，Java版挂Java容器。选型时注意匹配宿主环境，不要混装。装完之后Web Adaptor本身不会立即生效，还需要在浏览器里执行一个配置界面，完成对目标站点的注册。

3.2 创建ArcGIS GIS Server站点

GIS Server安装完成后，需要先创建站点才能被Web Adaptor认识。创建站点的入口在https://服务器名:6443/arcgis/manager或者首次访问https://服务器名:6443/arcgis时自动引导。

创建站点时要填写三个关键路径：

• 服务器目录：存放输出目录、缓存目录、日志等，默认会放在安装目录下，生产环境建议指到独立数据盘或共享存储；
• 配置存储：必须是共享目录（如果后续要做高可用），所有GIS Server节点都能访问，节点之间通过它同步站点配置；
• 内容目录：存放服务定义等站点内容，同样建议共享。

创建完站点后，GIS Server会启动一系列后台服务，包括Server Manager、Server Admin API、服务执行器。到这里，GIS Server站点已经独立可用了，可以通过https://服务器名:6443/arcgis/rest查看REST服务目录。

3.3 配置ArcGIS Data Store

Data Store的安装包通常是独立安装包，也可以和Server一起预装。安装本身很快，重点在后续配置。

首次访问Data Store配置界面https://服务器名:2443/arcgis/datastore（端口可能随实例偏移），会让你选择存储类型：

• 关系型数据存储：用于要素类、表格等业务数据，绝大多数场景必选；
• 切片缓存数据存储：用于缓存地图服务的切片，加速地图浏览；
• 时空大数据存储：用于大数据量、时空分析场景，只在特定业务下需要。

创建数据存储后，需要把Data Store注册到GIS Server站点上。这一步在GIS Server Manager的“站点”模块里完成，直接填写Data Store的管理地址和管理员账号密码。注册完成后，Server站点就能调用Data Store为Portal提供托管数据库服务。

这里特别提醒：Data Store装了之后和GIS Server是独立服务，不是装完自动关联的。我见过不少人跳过了注册步骤，Portal发布了托管要素服务，结果后台一直报“无法连接数据存储”，其实问题就出在注册这一步。

3.4 创建Portal站点并完成联合

GIS Server和Data Store打通了，Portal可以上场了。首次访问https://服务器名:7443/arcgis进入Portal初始配置界面，创建门户站点。

创建Portal站点时需要设置：

• 初始管理员账号，一般是admin加一个强密码；
• 门户站点名称，就是对外显示的名称；
• 安全问答，用于找回管理员账号，务必记好；
• 内容目录和配置存储路径，同样建议放到共享位置。

Portal创建完成后，最重要的就是联合操作。所谓联合，就是把前面搭好的GIS Server站点交给Portal管理，Portal作为总入口统一调度。

联合操作在Portal管理后台的“服务器”模块里配置：

• 点击“添加联合服务器”；
• 填写GIS Server的REST服务地址，如https://服务器名:6443/arcgis；
• 填写一个内置的管理员用户名密码（因为联合后会移除本地账号体系，改用Portal账号）；
• 系统会验证连通性，通过后完成联合。

联合成功后，GIS Server就完全纳入Portal的管理范畴，Server原来的本地管理员登录方式会被替代。以后发布服务、处理服务、托管服务，全都在Portal里统一操作。

3.5 统一入口与最终联调

四个组件各自都能跑通，最后一步是用Web Adaptor把内外访问通道理顺。

Web Adaptor配置界面的逻辑很简单：新增一个条目，指定它负责的外部URL路径，再指向后端的实际服务地址。我常用的做法是注册两个条目：

• 路径portal→ 指向Portal的https://服务器名:7443/arcgis/portal；
• 路径server→ 指向GIS Server的https://服务器名:6443/arcgis。

这样对外部用户来说，只需要记住一个域名，比如https://gis.example.com/portal/home就能进门户，https://gis.example.com/server/rest就能访问REST服务。Web Adaptor自动根据路径把请求分发到后端，外部用户完全不需要知道内部拓扑。

联调验证我固定走一遍流程：

1. 浏览器访问外部门户地址，能打开Portal首页并正常登录；
2. 在门户中新建一个Web地图，添加一个底图服务，确认可以正常加载；
3. 发布一个托管要素服务到Data Store，确认数据能从门户端完成生命周期管理；
4. 发布一个由GIS Server计算的分析服务，确认Server资源能被调度执行。

这四步全部通过，一套ArcGIS Enterprise才算是真正“跑通”了。

4. 部署与交付中最常见的坑及排查方法

做了这么多次部署，我把高频问题整理出来，基本都是每次都能遇到的。

4.1 证书和HTTPS问题

最典型的表现：浏览器访问门户时，地址栏提示“不安全”，或者Portal后台提示“Portal communication is insecure”。

原因十有八九是自签名证书导致的信任链问题。解决思路也简单：生产环境装正式签发的证书，测试环境要么把自签名证书导入本机受信任根证书颁发机构，要么干脆在浏览器里点击“继续访问”——但后者会导致很多API调用被浏览器拦截。

还有一个常见场景：通配符证书部署好了，但并没有覆盖所有用到的子域名。比如证书只覆盖*.gis.example.com，结果内部访问用的是Portal的机器名portal-01，浏览器照样报警。解决办法就是保证所有组件访问地址都落在同一个受信任域名体系里。

4.2 Web Adaptor注册失败

Web Adaptor注册站点时，有时候会报“HTTP 404”或“无法识别站点”。多数情况下是两个原因：

一是URL路径填错了。Web Adaptor配置的是对外访问的路径，但内部转发地址一定要指向目标实际的服务地址，并且要以/arcgis结尾，少了这个关键路径后缀，基本必报404。

二是Web Adaptor所在主机和目标站点不在同一台机器时，网络不通或端口没放通。记住一个规律：Web Adaptor到Server、到Portal之间必须有网络通路，且端口能连通，这个在前面章节已经特别强调过。

4.3 Data Store起不来

Data Store安装了，但在配置界面里一直显示“服务未启动”，或者注册到GIS Server时提示连接失败。

排查从两个地方下手：

• 进程活着没有？Windows看服务管理器，Linux看命令ps -ef | grep datastore；
• 数据目录有没有初始化？Data Store第一次启动会在数据目录里写数据库文件，如果目录不存在或没有写入权限，服务起不来。

另外，Data Store对磁盘空间比较敏感，数据目录所在盘快满了，服务也可能异常停止。提前规划好磁盘容量，比事后扩容省心得多。

4.4 联合失败排查

Portal联合GIS Server失败的场景，我遇到过的原因大概这么几种：

• 两台服务器时间不同步：Kerberos和OAuth2的票据校验依赖时间戳，时间差超过几分钟就会校验失败。部署前统一做NTP时间同步，这是很有必要的；
• 访问地址不一致：Portal填写Server的URL时，用了机器名，但Server侧实际只能用IP访问，反向解析失败导致联合不通过。统一使用完整域名或机器名，保证两边一致；
• 安全问答遗忘：联合操作需要求解Portal的问题，很多人这会才想起来安全问答答案没记，导致配置文件无法导出，只能重置Portal站点。部署时一定要把安全问答存在自己的密码本里。

4.5 问题速查表

5. 部署完了，运维和扩展也要心里有数

平台跑通了，交付就算完成了吗？以我的经验，部署只是开始，后续的运维和扩展才是真正的持久战。

5.1 备份：哪些东西必须定期备份

ArcGIS Enterprise里有三类东西丢失了很难重建：

Portal内容与配置：门户成员、角色、内容项、权限设置。备份方式是在Portal管理后台执行“导出站点”操作，导出的文件里打包了配置存储和内容目录的元数据。

GIS Server站点配置：服务定义、站点配置、安全配置。可以通过Server Manager的“导出站点配置”完成，导出的是站点配置JSON。

Data Store数据：真实的空间数据文件。最简单的思路是对Data Store数据目录做定期文件级备份，有条件的话做数据库快照。

备份原则很简单：几台机器分别备份，宁可冗余不可缺失。我第一次做部署时只备份了Portal，没备份Data Store，结果数据误删后只能按天级恢复，损失不小。

5.2 扩展：从双机到高可用怎么加节点

如果项目上线后访问量涨上来了，需要增强ArcGIS Enterprise的可用性，扩展步骤也是固定的。

GIS Server扩展最常规：在新的服务器上安装ArcGIS GIS Server，然后通过Server Manager执行“加入现有站点”，填现有站点的管理地址和管理员账号，节点就加进去了。加完节点后，Web Adaptor会把请求负载均衡到多个节点上，相当于无状态服务的水平扩容。

Data Store高可用：配置一个备用节点，指定的主节点数据会自动复制到备用节点。注意Data Store高可用必须建立在共享存储的基础上，而且备用节点和主节点的配置要保持一致。

Portal高可用麻烦一些，因为是状态型服务，需要保证内容目录和配置存储在共享存储上，然后配置两台Portal节点共享同一个站点配置，通过Web Adaptor做负载均衡。一个小技巧是：Portal高可用尽量在首次创建站点的时候就配置成共享模式，后期改造要处理很多迁移步骤。

5.3 升级与版本跟进的小经验

ArcGIS Enterprise版本升级，我的经验是“小步快跑，不要跳级”。升级前必须完成以下几步：

• 导出门户站点备份，确认备份文件可恢复；
• 导出GIS Server站点配置；
• 停掉Portal、Server、Data Store的站点服务；
• 按官方升级顺序先升级Data Store，再升级GIS Server，最后升级Portal；
• 重启服务，逐一验证。

跳版本升级很容易出现兼容性问题，尤其是Portal和Server版本不一致的时候，联合状态会频繁报错。我习惯先把所有组件版本对齐，再做功能验证。

另外，平台依赖的Web容器（如Tomcat、IIS）和Java环境也要纳入升级计划。很多诡异的问题是Web容器版本过旧导致的会话丢失，而不是ArcGIS组件本身的问题。

最后说点实在的

做了这么多次ArcGIS Enterprise部署，我个人最大的体会是：这套平台的部署，本质上不是软件安装，而是一个小型的架构交付项目。组件之间的关系、环境的每一项规划、证书与域名的统一设计，都比“点下一步安装”更值得花精力。

如果只能给大家留下一条建议，那就是：不要在环境没准备好的时候急着装组件。把主机名、域名、证书、共享目录、端口、账号这六件事一次性规划到位，后面的部署流程顺畅得会让你怀疑是不是换了一个产品。我踩过的所有大坑，几乎都发生在“跳过了环境准备直接安装”的项目里。

希望这篇文章能帮你少走一些弯路。等平台真正稳定跑起来之后，你再回头看，会发现当初花在前期规划上的时间，一分都没有白费。