参考配置会出现哪些问题

这个问题貌似是jar包冲突所导致，我之前遇见过相同的问题。你导入了哪些jar包，贴图出来看看######struts2-convention-plugin-2.3.16.3.jar struts2-core-2.3.16.3.jar struts2-json-plugin-2.3.16.3.jar struts2-spring-plugin-2.3.16.3.jar xwork-core-2.3.16.3.jar 版本都是一致的。###### struts2-convention-plugin-2.3.16.3.jar struts2-core-2.3.16.3.jar struts2-json-plugin-2.3.16.3.jar struts2-spring-plugin-2.3.16.3.jar xwork-core-2.3.16.3.jar 版本都是一致的。 ######不是struts2的包，是其它的包与struts2有冲突###### 虽然时间过去2年了.我还是补个答案吧, 出现这个问题,是因为使用 了Codebehind Plugin的包(你可以去查找下你的jar包，有这两个关键字的)。貌似早期这个的使用需要去web.xml文件里面，在struts的过滤器下配置init-param参数，参数名为actionPackages，参数的值是你的使用了annotation标签的java文件，这样他才会解析annotation。出现上面那个报错的原因，就是因为Codebehind Plugin他需要上面配置的参数去查找配置annotation的类，而没有配置的情况下，他找不到，于是报那个问题。 在2.1之后，使用了Convention Plugin 替代了Codebehind Plugin ，所以已经不需要配置init-param参数，所以你可以直接去掉Codebehind Plugin 的包，只要遵守Convention Plugin 要求的规则，他就会自动去解析对应的使用了annotation的文件，大致规则就是： 1. 扫描其位于包（ “struts, struts2, action 或 actions“）的命名注解的类. 2. 接着，扫描相匹配下列任一条件的文件：   实例了 com.opensymphony.xwork2.Action 接口。   扩展了 com.opensymphony.xwork2.ActionSupport 类   文件名用动作(例如：UserAction，LoginAction)结束 （参考内容：http://struts.apache.org/docs/convention-plugin.html#ConventionPlugin-Introduction ，在介绍的时候就写明了） 我不确认你是不是跟我一样的问题，我是使用annotation的时候发现的。因为我只使用了No mapping found for dependency [type=java.lang.String, 这几个关键字来查询。不过看这句的意思是没有发现依赖的配置信息，我想多半是在加载的时候找不到action的配置信息，所以把我的原因写上，有后来者的话可以参考下。

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点，圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关注点 (technical concerns)？需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型？笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设，同时在这块也投入了很多时间去学习和研究，有一些经验和学习心得，可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务，同时服务提供方一般以集群方式提供服务，也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同，目前主要的服务注册、发现和负载均衡方案有三种： 第一种是集中式 LB 方案，如下图 Fig 1，在服务消费者和服务提供者之间有一个独立的 LB，LB 通常是专门的硬件设备如 F5，或者基于软件如 LVS，HAproxy 等实现。LB 上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向 LB 发起请求，由 LB 以某种策略（比如 Round-Robin）做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力，能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢？通常的做法是通过 DNS，运维人员为服务配置一个 DNS 域名，这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单，在 LB 上也容易做集中式的访问控制，这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题，所有服务调用流量都经过 LB，当服务数量和调用量大的时候，LB 容易成为瓶颈，且一旦 LB 发生故障对整个系统的影响是灾难性的。另外，LB 在服务消费方和服务提供方之间增加了一跳 (hop)，有一定性能开销。 第二种是进程内 LB 方案，针对集中式 LB 的不足，进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头，该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案，下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现，服务提供方启动时，首先将服务地址注册到服务注册表（同时定期报心跳到服务注册表以表明服务的存活状态，相当于健康检查），服务消费方要访问某个服务时，它通过内置的 LB 组件向服务注册表查询（同时缓存并定期刷新）目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高，一般采用能满足高可用分布式一致的组件（例如 Zookeeper, Consul, Etcd 等）来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案，LB 和服务发现能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好。但是，该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头，如果企业内有多种不同的语言栈，就要配合开发多种不同的客户端，有一定的研发和维护成本。另外，一旦客户端跟随服务调用方发布到生产环境中，后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架，对应的组件分别是：Eureka 服务注册表，Karyon 服务端框架支持服务自注册和健康检查，Ribbon 客户端框架支持服务自发现和软路由。另外，阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案，该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将 LB 和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡，见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案，没有单点问题，一个 LB 进程挂了只影响该主机上的服务调用方，服务调用方和 LB 之间是进程内调用，性能好，同时，该方案还简化了服务调用方，不需要为不同语言开发客户库，LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂，环节多，出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架，对应组件分别是：Zookeeper 作为服务注册表，Nerve 独立进程负责服务注册和健康检查，Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes，其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关 (Service Gateway)，见图 Fig 4，网关是连接企业内部和外部系统的一道门，有如下关键作用： 服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试 (Surgical debugging)，金丝雀测试 (Canary Testing)，数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层，有一定的计算逻辑，一般以集群方式部署，前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul，特点是动态可热部署的过滤器 (filter) 机制，其它如 HAproxy，Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务 Middle Tier Service）和前端服务（也称边缘服务 Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如 PC，Pad 或者 Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似 Proxy 代理或者 Façade 门面模式，而服务注册表和服务自注册自发现类似 IoC 依赖注入模式，微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源 (线程，队列等) 被耗尽，造成所谓的雪崩效应 (Cascading Failure，见图 Fig 7)，严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践，业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践，主要包括： Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图，正常状态下，电路处于关闭状态 (Closed)，如果调用持续出错或者超时，电路被打开进入熔断状态 (Open)，后续一段时间内的所有调用都会被拒绝 (Fail Fast)，一段时间以后，保护器会尝试进入半熔断状态 (Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern)，顾名思义，该模式像舱壁一样对资源或失败单元进行隔离，如果一个船舱破了进水，只损失一个船舱，其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子，假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务，且部署 A 的容器一共有 120 个工作线程，采用线程隔离机制，可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程，当 Svc2 慢了，给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽，线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响，如果没有这种隔离机制，当 Svc2 慢的时候，120 个工作线程会很快全部被对 Svc2 的调用吃光，整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder)，服务总有容量限制，没有限流机制的服务很容易在突发流量 (秒杀，双十一) 时被冲垮。限流通常指对服务限定并发访问量，比如单位时间只允许 100 个并发调用，对超过这个限制的请求要拒绝并回退。回退 (fallback)，在熔断或者限流发生的时候，应用程序的后续处理逻辑是什么？回退是系统的弹性恢复能力，常见的处理策略有，直接抛出异常，也称快速失败 (Fail Fast)，也可以返回空值或缺省值，还可以返回备份数据，如果主服务熔断了，可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中，凡是需要容错的依赖点 (服务，缓存，数据库访问等)，开发人员只需要将调用封装在 Hystrix Command 里头，则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证，是 Netflix 微服务平台稳定性和弹性的基石，正逐渐被社区接受为标准容错组件。 服务框架微服务化以后，为了让业务开发人员专注于业务逻辑实现，避免冗余和重复劳动，规范研发提升效率，必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑，包括： Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查，假定采用进程内 LB 方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。监控日志，框架一方面要记录重要的框架层日志、metrics 和调用链数据，还要将日志、metrics 等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。REST/RPC 和序列化，框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来，HTTP/REST 是当前主流 API 暴露方式，在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出 Ajax 友好的 JSON 消息格式，而对无线设备上的 Native App，框架支持输出性能高的 Binary 消息格式。配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon，Spring 的 Spring Boot/Cloud，阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境 (开发 / 测试 / 生产) 一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期可能还要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置，简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上，用户通过管理界面配置和调整服务配置，具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置，拉方式比较可靠，但会有延迟同时有无效网络开销 (假设配置不常更新)，服务器推方式能及时更新配置，但是实现较复杂，一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题，对于大规模服务化环境，配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf，360 的 QConf，Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司，几年前，Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件包括： Eureka:　服务注册发现框架Zuul:　服务网关Karyon:　服务端框架Ribbon:　客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系，来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品，主要是基于对 Netflix 开源组件的进一步封装，方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说，充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。 原文地址：https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C

Layout Go工程项目的整体组织 首先我们看一下整个 Go 工程是怎么组织起来的。 很多同事都在用 GitLab 的，GitLab 的一个 group 里面可以创建很多 project。如果我们进行微服务化改造，以前很多巨石架构的应用可能就拆成了很多个独立的小应用。那么这么多小应用，你是要建 N 个 project 去维护，还是说按照部门或者组来组织这些项目呢？在 B 站的话，我们之前因为是 Monorepo，现在是按照部门去组织管理代码，就是说在单个 GitLab 的 project 里面是有多个 app 的，每一个 app 就表示一个独立的微服务，它可以独立去交付部署。所以说我们看到下面这张图里面，app 的目录里面是有好多个子目录的，比方说我们的评论服务，会员服务。跟 app 同级的目录有一个叫 pkg，可以存放业务有关的公共库。这是我们的一个组织方式。当然，还有一种方式，你可以按照 GitLab 的 project 去组织，但我觉得这样的话可能相对要创建的 project 会非常多。 如果你按部门组织的话，部门里面有很多 app，app 目录怎么去组织？我们实际上会给每一个 app 取一个全局唯一名称，可以理解为有点像 DNS 那个名称。我们对业务的命名也是一样的，我们基本上是三段式的命名，比如账号业务，它是一个账号业务、服务、子服务的三段命名。三段命名以后，在这个 app 目录里面，你也可以按照这三层来组织。比如我们刚刚说的账号目录，我可能就是 account 目录，然后 VIP，在 VIP 目录下可能会放各种各样的不同角色的微服务，比方说可能有一些是做 job，做定时任务或者流式处理的一些任务，有可能是做对外暴露的 API 的一些服务，这个就是我们关于整个大的 app 的组织的一种形式。 微服务中的 app 服务分类 微服务中单个 app 的服务里又分为几类不同的角色。我们基本上会把 app 分为 interface（BFF）、service、job（补充：还有一个 task，偏向定时执行，job 偏向流式） 和 admin。 Interface 是对外的业务网关服务，因为我们最终是面向终端用户的 API，面向 app，面向 PC 场景的，我们把这个叫成业务网关。因为我们不是统一的网关，我们可能是按照大的业务线去独立分拆的一些子网关，这个的话可以作为一个对外暴露的 HTTP 接口的一个目录去组织它的代码，当然也可能是 gRPC 的（参考 B 站对外的 gRPC Moss 分享）。 Service 这个角色主要是面向对内通信的微服务，它不直接对外。也就是说，业务网关的请求会转发或者是会 call 我们的内部的 service，它们之间的通讯可能是使用自己的 RPC，在 b 站我们主要是使用 gRPC。使用 gRPC 通讯以后，service 它因为不直接对外，service 之间可能也可以相互去 call。 Admin 区别于 service，很多应用除了有面向用户的一些接口，实际上还有面向企业内部的一些运营侧的需求，通常数据权限更高，从安全设计角度需要代码物理层面隔离，避免意外。 第四个是 ecode。我们当时也在内部争论了很久，我们的错误码定义到底是放在哪里？我们目前的做法是，一个应用里面，假设你有多种角色，它们可能会复用一些错误码。所以说我们会把我们的 ecode 给单独抽出来，在这一个应用里面是可以复用的。注意，它只在这一个应用里面复用，它不会去跨服跨目录应用，它是针对业务场景的一个业务错误码的组织。 App 目录组织 我们除了一个应用里面多种角色的这种情况，现在展开讲一下具体到一个 service 里面，它到底是怎么组织的。我们的 app 目录下大概会有 api、cmd、configs、 internal 目录，目录里一般还会放置 README、CHANGELOG、OWNERS。 API 是放置 api 定义以及对应的生成的 client 代码，包含基于 pb 定义（我们使用 PB 作为 DSL 描述 API） 生成的 swagger.json。 而 cmd，就是放 main 函数的。Configs 目录主要是放一些服务所需的配置文件，比方说说我们可能会使用 TOML 或者是使用 YAML 文件。 Internal 的话，它里面有四个子目录，分别是 model、dao、service 和 server。Model 的定位职责就是对我们底层存储的持久化层或者存储层的数据的映射，它是具体的 Go 的一个 struct。我们再看 dao，你实际就是要操作 MySQL 或者 Redis，最终返回的就是这些 model（存储映射）。Service 组织起来比较简单，就是我们通过 dao 里面的各个方法来完成一个完整的业务逻辑。我们还看到有个 server，因为我一个微服务有可能企业内部不一定所有 RPC 都统一，那我们处于过渡阶段，所以 server 里面会有两个小目录，一个是 HTTP 目录，暴露的是 HTTP 接口，还有一个是 gRPC 目录，我们会暴露 gRPC 的协议。所以在 server 里面，两个不同的启动的 server，就是说一个服务和启动两个端口，然后去暴露不同的协议，HTTP 接 RPC，它实际上会先 call 到 service，service 再 call 到 dao，dao 实际上会使用 model 的一些数据定义 struct。但这里面有一个非常重要的就是，因为这个结构体不能够直接返回给我们的 api 做外对外暴露来使用，为什么？因为可能从数据库里面取的敏感字段，当我们实际要返回到 api 的时候，可能要隐藏掉一些字段，在 Java 里面，会抽象的一个叫 DTO 的对象，它只是用来传输用的，同理，在我们 Go 里面，实际也会把这些 model 的一些结构体映射成 api 里面的结构体（基于 PB Message 生成代码后的 struct）。 Rob Pike 当时说过的一句话，a little copying is better than a little dependency，我们就遵循了这个理念。在我们这个目录结构里面，有 internal 目录，我们知道 Go 的目录只允许这个目录里面的人去 import 到它，跨目录的人实际是不能直接引用到它的。所以说，我们看到 service 有一个 model，那我的 job 代码，我做一些定时任务的代码或者是我的网关代码有可能会映射同一个 model，那是不是要把这个 model 放到上一级目录让大家共享？对于这个问题，其实我们当时内部也争论过很久。我们认为，每一个微服务应该只对自己的 model 负责，所以我们宁愿去做一小部分的代码 copy，也不会去为了几个服务之间要共享这一点点代码，去把这个 model 提到和 app 目录级别去共用，因为你一改全错，当然了，你如果是拷贝的话，就是每个地方都要去改，那我们觉得，依赖的问题可能会比拷贝代码相对来说还是要更复杂的。 这个是一个标准的 PB 文件，就是我们内部的一个 demo 的 service。最上面的 package 是 PB 的包名，demo.service.v1，这个包使用的是三段式命名，全局唯一的名称。那这个名称为什么不是用 ID？我见过有些公司对内部做的 CMDB 或者做服务树去管理企业内部微服务的时候，是用了一些名称加上 ID 来搞定唯一性，但是我们知道后面那一串 ID 数字是不容易被传播或者是不容易被记住的，这也是 DNS 出来的一个意义，所以我们用绝对唯一的一个名称来表示这个包的名字，在后面带上这一个 PB 文件的版本号 V1。 我们看第二段定义，它有个 Service Demo 代码，其实就表示了我们这个服务要启动的服务的一个名称，我们看到这个服务名称里面有很多个 RPC 的方法，表示最终这一个应用或者这个 service 要对外暴露这几个 RPC 的方法。这里面有个小细节，我们看一下 SayHello 这个方法，实际它有 option 的一个选项。通过这一个 PB 文件，你既可以描述出你要暴露的是 gRPC 协议，又暴露出 HTTP 的一个接口，这个好处是你只需要一个 PB 文件描述你暴露的所有 api。我们回想一下，我们刚刚目录里面有个 api 目录，实际这里面就是放这一个 PB 文件，描述这一个工程到底返回的接口是什么。不管是 gRPC 还是 HTTP 都是这一个文件。还有一个好处是什么？实际上我们可以在 PB 文件里面加上很多的注释。用 PB 文件的好处是你不需要额外地再去写文档，因为写文档和写服务的定义，它本质上是两个步骤，特别容易不一致，接口改了，文档不同步。我们如果基于这一个 PB 文件，它生成的 service 代码或者调用代码或者是文档都是唯一的。 依赖顺序与 api 维护 就像我刚刚讲到的，model 是一个存储层的结构体的一一映射，dao 处理一些数据读写包，比方说数据库缓存，server 的话就是启动了一些 gRPC 或者 HTTP Server，所以它整个依赖顺序如下：main 函数启动 server，server 会依赖 api 定义好的 PB 文件，定义好这些方法或者是服务名之后，实际上生成代码的时候，比方说 protocbuf 生成代码的时候，它会把抽象 interface 生成好。然后我们看一下 service，它实际上是弱依赖的 api，就是说我的 server 启动以后，要注册一个具体的业务代码的逻辑，映射方法，映射名字，实际上是弱依赖的 api 生成的 interface 的代码，你就可以很方便地启动你的 server，把你具体的 service 的业务逻辑给注入到这个 server，和方法进行一一绑定。最后，dao 和 service 实际上都会依赖这个 model。 因为我们在 PB 里面定义了一些 message，这些 message 生成的 Go 的 struct 和刚刚 model 的 struct 是两个不同的对象，所以说你要去手动 copy 它，把它最终返回。但是为了快捷，你不可能每次手动去写这些代码，因为它要做 mapping，所以我们又把 K8s 里类似 DeepCopy 的两个结构体相互拷贝的工具给抠出来了，方便我们内部 model 和 api 的 message 两个代码相互拷贝的时候，可以少写一些代码，减少一些工作量。 上面讲的就是我们关于工程的一些 layout 实践。简单回溯一下，大概分为几块，第一就是 app 是怎么组织的，app 里面有多种角色的服务是怎么组织的，第三就是一个 app 里面的目录是怎么组织的，最后我重点讲了一下 api 是怎么维护的。 Unittest 测试方法论 现在回顾一下单元测试。我们先看这张图，这张图是我从《Google 软件测试之道》这本书里面抠出来的，它想表达的意思就是最小型的测试不能给我们的最终项目的质量带来最大的信心，它比较容易带来一些优秀的代码质量，良好的异常处理等等。但是对于一个面向用户场景的服务，你只有做大型测试，比方做接口测试，在 App 上验收功能的这种测试，你应用交付的信心可能会更足。这个其实要表达的就是一个“721 原则”。我们就是 70% 写小型测试，可以理解为单元测试，因为它相对来说好写，针对方法级别。20% 是做一些中型测试，可能你要连调几个项目去完成你的 api。剩下 10% 是大型测试，因为它是最终面向用户场景的，你要去使用我们的 App，或者用一些测试 App 去测试它。这个就是测试的一些简单的方法论。 单元测试原则 我们怎么去对待 Go 里面的单元测试？在《Google 软件测试之道》这本书里面，它强调的是对于一个小型测试，一个单元测试，它要有几个特质。它不能依赖外部的一些环境，比如我们公司有测试环境，有持续集成环境，有功能测试环境，你不能依赖这些环境构建自己的单元测试，因为测试环境容易被破坏，它容易有数据的变更，数据容易不一致，你之前构建的案例重跑的话可能就会失败。 我觉得单元测试主要有四点要求。第一，快速，你不能说你跑个单元测试要几分钟。第二，要环境一致，也就是说你跑测试前和跑测试后，它的环境是一致的。第三，你写的所有单元测试的方法可以以任意顺序执行，不应该有先后的依赖，如果有依赖，也是在你测试的这个方法里面，自己去 setup 和 teardown，不应该有 Test Stub 函数存在顺序依赖。第四，基于第三点，你可以做并行的单元测试，假设我写了一百个单元测试，一个个跑肯定特别慢。 doker-compose 最近一段时间，我们演进到基于 docker-compose 实现跨平台跨语言环境的容器依赖管理方案，以解决运行 unittest 场景下的容器依赖问题。 首先，你要跑单元测试，你不应该用 VPN 连到公司的环境，好比我在星巴克点杯咖啡也可以写单元测试，也可以跑成功。基于这一点，Docker 实际上是非常好的解决方式。我们也有同学说，其他语言有一些 in-process 的 mock，是不是可以启动 MySQL 的 mock ，然后在 in-process 上跑？可以，但是有一个问题，你每一个语言都要写一个这样的 mock ，而且要写非常多种，因为我们中间件越来越多，MySQL，HBase，Kafka，什么都有，你很难覆盖所有的组件 Mock。这种 mock 或者 in-process 的实现不能完整地代表线上的情况，比方说，你可能 mock 了一个 MySQL，检测到 query 或者 insert ，没问题，但是你实际要跑一个 transaction，要验证一些功能就未必能做得非常完善了。所以基于这个原因，我们当时选择了 docker-compose，可以很好地解决这个问题。 我们对开发人员的要求就是，你本地需要装 Docker，我们开发人员大部分都是用 Mac，相对来说也比较简单，Windows 也能搞定，如果是 Linux 的话就更简单了。本地安装 Docker，本质上的理解就是无侵入式的环境初始化，因为你在容器里面，你拉起一个 MySQL，你自己来初始化数据。在这个容器被销毁以后，它的环境实际上就满足了我们刚刚提的环境一致的问题，因为它相当于被重置了，也可以很方便地快速重置环境，也可以随时随地运行，你不需要依赖任何外部服务，这个外部服务指的是像 MySQL 这种外部服务。当然，如果你的单元测试依赖另外一个 RPC 的 service 的话，PB 的定义会生成一个 interface，你可以把那个 interface 代码给 mock 掉，所以这个也是能做掉的。对于小型测试来说，你不依赖任何外部环境，你也能够快速完成。 另外，docker-compose 是声明式的 API，你可以声明你要用 MySQL，Redis，这个其实就是一个配置文件，非常简单。这个就是我们在单元测试上的一些实践。 我们现在看一下，service 目录里面多了一个 test 目录，我们会在这个里面放 docker-compose 的 YAML 文件来表示这次单元化测试需要初始化哪些资源，你要构建自己的一些测试的数据集。因为是这样的，你是写 dao 层的单元测试的话，可能就需要 database.sql 做一些数据的初始化，如果你是做 service 的单元测试的话，实际你可以把整个 dao 给 mock 掉，我觉得反而还相对简单，所以我们主要针对场景就是在 dao 里面偏持久层的，利用 docker-compose 来解决。 容器的拉起，容器的销毁，这些工作到底谁来做？是开发同学自己去拉起和销毁，还是说你能够把它做成一个 Library，让我们的同学写单元测试的时候比较方便？我倾向的是后者。所以在我们最终写单元测试的时候，你可以很方便地 setup 一个依赖文件，去 setup 你的容器的一些信息，或者把它销毁掉。所以说，你把环境准备好以后，最终可以跑测试代码也非常方便。当然我们也提供了一些命令函，就是 binary 的一些工具，它可以针对各个语言方便地拉起容器和销毁容器，然后再去执行代码，所以我们也提供了一些快捷的方式。 刚刚我也提到了，就是我们对于 service 也好，API 也好，因为依赖下层的 dao 或者依赖下层的 service，你都很方便 mock 掉，这个写单元测试相对简单，这个我不展开讲，你可以使用 GoMock 或者 GoMonkey 实现这个功能。 Toolchain 我们利用多个 docker-compose 来解决 dao 层的单元测试，那对于我刚刚提到的项目的一些规范，单元测试的一些模板，甚至是我写了一些 dao 的一些占位符，或者写了一些 service 代码的一些占位符，你有没有考虑过这种约束有没有人会去遵循？所以我这里要强调一点，工具一定要大于约束和文档，你写了约束，写了文档，那么你最终要通过工具把它落实。所以在我们内部会有一个类似 go tool 的脚手架，叫 Kratos Tool，把我们刚刚说的约定规范都通过这个工具一键初始化。 对于我们内部的工具集，我们大概会分为几块。第一块就是 API 的，就是你写一个 PB 文件，你可以基于这个 PB 文件生成 gRPC，HTTP 的框架代码，你也可以基于这个 PB 文件生成 swagger 的一些 JSON 文件或者是 Markdown 文件。当然了，我们还会生成一些 API，用于 debug 的 client 方便去调试，因为我们知道，gRPC 调试起来相对麻烦一些，你要去写代码。 还有一些工具是针对 project 的，一键生成整个应用的 layout，非常方便。我们还提了 model，就是方便 model 和 DTO，DTO 就是 API 里面定义的 message 的 struct 做 DeepCopy，这个也是一个工具。 对于 cache 的话，我们操作 memcache，操作 Redis 经常会要做什么逻辑？假如我们有一个 cache aside 场景，你读了一个 cache，cache miss 要回原 DB，你要把这个缓存回塞回去，甚至你可能这个回塞缓存想异步化，甚至是你要去读这个 DB 的时候要做归并回源（singleflight），我们把这些东西做成一些工具，让它整个回源到 DB 的逻辑更加简单，就是把这些场景描述出来，然后你通过工具可以一键生成这些代码，所以也是会比较方便。 我们再看最后一个，就是 test 的一些工具。我们会基于项目里面，比方说 dao 或者是 service 定义的 interface 去帮你写好 mock 的代码，我直接在里面填，只要填代码逻辑就行了，所以也会加速我们的生产。 上图是 Kratos 的一个 demo，基本就是支持了一些 command。这里就是一个 kratos new kratos-demo 的一个工程，-d YourPath 把它导到某一个路径去，--proto 顺便把 API 里面的 proto 代码也生成了，所以非常简单，一行就可以很快速启动一个 HTTP 或者 gRPC 服务。 我们知道，一个微服务的框架实际非常重，有很多初始化的方式等等，非常麻烦。所以说，你通过脚手架的方式就会非常方便，工具大于约定和文档这个这个理念就是这么来的。 Configuration 讲完工具以后，最后讲一下配置文件。我为什么单独提一下配置文件？实际它也是工程化的一部分。我们一个线上的业务服务包含三大块，第一，应用程序，第二，配置文件，第三，数据集。配置文件最容易导致线上出 bug，因为你改一行配置，整个行为可能跟 App 想要的行为完全不一样。而且我们的代码的开发交付需要经过哪些流程？需要 commit 代码，需要 review，需要单元测试，需要 CD，需要交付到线上，需要灰度，它的整个流程是非常长的。在一步步的环境里面，你的 bug 需要前置解决，越前置解决，成本越低。因为你的代码的开发流程是这么一个 pipeline，所以 bug 最终流到线上的概率很低，但是配置文件没有经过这么复杂的流程，可能大家发现线上有个问题，决定要改个线上配置，就去配置中心或者配置文件改，然后 push 上线，接着就问题了，这个其实很常见。 从 SRE 的角度来说，导致线上故障的主因就是来自配置变更，所以 SRE 很大的工作是控制变更管理，如果能把变更管理做好，实际上很多问题都不会出现。配置既然在整个应用里面这么重要，那在我们整个框架或者在 Go 的工程化实践里面，我们应该对配置文件做一些什么事情？ 我觉得是几个。第一，我们的目标是什么？配置文件不应该太复杂，我见过很多框架，或者是业务的一些框架，它实际功能非常强大，但是它的配置文件超级多。我就发现有个习惯，只要有一个同事写错了这个配置，当我新起一个项目的时候，一定会有人把这个错误的配置拷贝到另外一个系统里面去。然后当发现这个应用出问题的时候，我们一般都会内部说一下，你看看其他同事有没有也配错的，实际这个配错概率非常高。因为你的配置选项越多，复杂性越高，它越容易出错。所以第一个要素就是说，尽量避免复杂的配置文件。配得越多，越容易出错。 第二，实际我们的配置方式也非常多，有些用 JSON，有些用 YAML，有些用 Properties，有些用 INI。那能不能收敛成通用的一种方式呢？无论它是用 Python 的脚本也好，或者是用 JSON 也好，你只要有一种唯一的约定，不需要太多样的配置方式，对我们的运维，对我们的 SRE 同时来说，他跨项目的变更成本会变低。 第三，一定要往简单化去努力。这句话其实包含了几个方面的含义。首先，我们很多配置它到底是必须的还是可选的，如果是可选，配置文件是不是就可以把它踢掉，甚至不要出现？我曾经有一次看到我们 Java 同事的配置 retry 有一个重试默认是零，内部重试是 80 次，直接把 Redis cluster 打故障了，为什么？其实这种事故很低级，所以简单化努力的另外一层含义是指，我们在框架层面，尤其是提供 SDK 或者是提供 framework 的这些同事尽量要做一些防御编程，让这种错配漏配也处于一个可控的范围，比方重试 80 次，你觉得哪个 SDK 会这么做？所以这个是我们要考虑的。但是还有一点要强调的是，我们对于业务开发的同事，我们的配置应该足够的简单，这个简单还包含，如果你的日志基本上都是写在这个目录，你就不要提供这个配置给他，反而不容易出错。但是对于我们内部的一些 infrastructure，它可能需要非常复杂的配置来优化，根据我的场景去做优化，所以它是两种场景，一种是业务场景，足够简单，一种是我要针对我的通用的 infrastructure 去做场景的优化，需要很复杂的配置，所以它是两种场景，所以我们要想清楚你的业务到底是哪一种形态。 还有一个问题就是我们配置文件一定要做好权限的变更和跟踪，因为我们知道上线出问题的时候，我们的第一想法不是查 bug，是先止损，止损先找最近有没有变更。如果发现有变更，一般是先回滚，回滚的时候，我们通常只回滚了应用程序，而忘记回滚了配置。每个公司可能内部的配置中心，或者是配置场景，或者跟我们的二进制的交付上线都不一样，那么这里的理念就是你的应用程序和配置文件一定是同一个版本，或者是某种意义上让他们产生一个版本的映射，比方说你的应用程序 1.0，你的配置文件 2.0，它们之间存在一个强绑定关系，我们在回滚的时候应该是一起回滚的。我们曾经也因为类似的一些不兼容的配置的变更，二进制程序上线，但配置文件忘记回滚，出现过事故，所以这个是要强调的。 另外，配置的变更也要经过 review，如果没问题，应该也是按照 App 发布一样，先灰度，再放量，再全量等等类似的一种方式去推，演进式的这种发布，我们也叫滚动发布，我觉得配置文件也是一样的思路。 加入阿里云钉钉群享福利：每周技术直播，定期群内有奖活动、大咖问答 原文链接

一 、iOS APP 上架流程简介 1. 申请开发者账号 苹果的开发者账号主要分为个人（Individual）、公司（Company）、企业（Enterprise）、高校（University）四种类型，每年资费分别为$99、$99、$299、免费）。一般开发者申请的都是个人或者公司的，企业的开发者账号开发应用不能发布到App Store，只能企业内部使用。这个申请过程一般可能需要一个星期左右。公司和企业的需要邓白氏码，如果邓白氏码未申请，请先申请邓白氏码，这个过程需要一到两个星期。 创建证书、AppID、生成描述文件 通过 Mac 的钥匙串工具，生成证书请求文件，下载证书，这里需要注意的是下载下来的证书只能在请求该证书的电脑上使用，如果想给其他开发者使用需要将已经导入的证书导出为个人信息交换（.p12）格式供他人使用。 AppID 的创建需要用到项目的 Bundle ID，之后便可以创建描述文件了。 在开发者中心的 iTunes Connect 中配置 App 相关信息 在开发者中心里的 iTunes Connect 里的 APP 选项中新建 APP 项目并配置相应的信息（需要各个版本的屏幕截图，运行模拟器，调到最大（command+1）用 command+s 截图，还有就是一个1024*1024的图标，不能有圆角） 使用 Xcode 打包上传 App 将 2 步骤中申请好的证书和描述文件正确配置到 Xcode 中，设置好Xcode 的一些属性： 在Xcode中选择iOS Device(这里不能选择模拟器) 如果应用不支持横屏，请在 General 选项中将 Landscape Left 和 Landscape Right 两项的勾选去掉 查看版本号和构建版本号 将断点、全局断点、僵尸模式等都去掉 设置为 Release 模式 之后便可选择 Xcode->Product->Archive 打包项目，打包完成后选择 Upload to App Store 上传。如果不想使用 Xcode 上传的话，也可以选择 Export 导出 ipa 文件， 需要注意的是在导出时，必须选择 Save for iOS App Store Deployment。然后通过Application Loader 工具上传 ipa 文件。 提交审核 以上步骤完成后，返回 iTunes Connect 上查看自己的 App 信息，在构建版本中选择刚刚上传的 App 版本，此时有可能显示正在处理，这时可能需要等几分钟再回来查看。选择好版本后点击提交以供审核，这时 App 会变成等待审核状态。 后续 后续就是等待苹果的审核人员审核应用了，如果一切顺利的话，这个过程需要一到两个工作日便可完成审核，当然前提是你的应用符合苹果的审核条款。如果审核不通过，请及时根据反馈信息修改应用，再次提交直到符合要求。审核通过后，如果之前选择已经选择好自动发布，便可在 AppStore 上查看和下载应用了。 二 、iOS 上架审核过程常见的坑与解决方法 1. 问题：用户生成内容（UGC）缺少必要的审核 为了防止非法滥用用户生成的内容，从而给用户提供虚假信息、盗取用户的知识产权，社交应用以及应用当中包含用户生成的信息的应用必须包括下述功能： 过滤不良内容 提供举报机制 后台服务可以提供阻止骚扰用户的行为 提供官方联系方式，让用户可以快速联系到开发商 解决方案： 维秀直播 App 提供了用户实时弹幕功能，所以涉及到了 UGC，他们的处理方法是增加关键词过滤，还有通过房管的方式人工审核，处理违规用户。 问题：应用中使用了 IDFA 被拒绝 IDFA 主要被用于广告中区分设备的作用。AppStore 禁止没有使用广告而采集 IDFA 的 App 上架，所以如果 App 本身没有广告的话，使用第三方 SDK 要注意检查是否含有 IDFA 广告模块。 解决方案： 如果应用本身有集成广告的话，只需要在提交审核的时候勾选正确的广告标识符选项即可。 如果应用本身未集成广告，却包含 IDFA 的话。这种情况一般都是集成的第三方 SDK 中包含 IDFA 导致的。首先寻找是否有不包含 IDFA 的 SDK 版本，如果没有的话可以参考 ShareSDK 的解决方法，通过后台配置在审核期间为应用添加广告，审核完成过后将广告展示去掉。 3. 问题：应用不支持 IPv6网络下使用 2016年6月1号起，苹果的审核人员会在 IPv6 网络上审核你的应用，所以如果你的应用程序无法使用 IPv6 协议，可能会被拒绝。 解决方案： 卓易夺宝和乐动听 App 上架过程中就因为 IPv6 的支持原因被拒。他们的解决方案是： 协调后端人员添加对 IPv6 网络的支持。 App 端更新相关的第三方 SDK，比如使用 ASI 或者 AFN 的版本太低,使用最新的 AFN 即可解决问题。 当然这些做完之后最好在Mac 上面搭建 IPv6网络供测试人员进行完测试再重新发布。 4. 问题：第三方登录、支付、分享未安装应用，提示下载被拒 这个问题其实被拒的原因有两种，第一种是未安装应用没有任何提示，这种情况下相当于应用有无效的按钮所以会被拒；第二种是提示下载对应的第三方 App，这也是苹果所不允许的。 解决方案： 最新的第三方登录等相关的 SDK 目前已知的（微信，QQ，微博）都已经对这种情况做了处理，在未安装的情况下会调用 web 进行登录，所以如果测试过程中发现可以成功在 web 上登录的话可以不做处理。以前在没有这种处理机制的情况下需要开发者调用对应接口，先判断是否安装了相应的第三方 APP，如果未安装，需要隐藏按钮，这样便可轻松过审。 问题：虚拟产品未使用应用内支付（IAP）被拒 根据苹果官方最新的审核条款：如果你希望通过付费才可以解锁你的应用当中的一些功能（例如，订阅内容，游戏货币，游戏关卡，获取优质内容，解锁完整版本），你必须使用应用内付费（IAP）。如果这种情况下，应用使用了其他的第三方支付，应用将被拒绝上架。 解决方案： 审核的时候，把相应的虚拟产品隐藏起来，通过后再放出来，此招有风险，可能会受到警告信，甚至被封号，如果用户量小就无所谓了，先把App 搞上架! 审核的时候，走 IAP 的支付方式，审核完成后再通过服务器配置动态切换到支付宝、微信等第三方支付。该法类似于方案1，也存在风险。 学习58同城，让用户去网站购买产品，买了产品的账号到移动端使用功能。 老老实实的使用 IAP 吧。 6. 问题：使用后台定位被拒 关于位置服务苹果的审核条款原文如下： 使用位置服务的应用程序必须提供和位置服务直接相关的功能。使用基于位置的API不允许用于提供紧急服务，或者实现自动控制车辆、飞行器以及其他设备（小型的设备例如小型无人机和玩具例外），远程控制汽车警报系统等。在收集、传输和使用用户的位置数据之前，请确保你已经取得了用户的同意。 如果应用程序使用了后台定位服务，务必在应用当中阐明其目的。并且使用后台定位的话需要提供一个明确的提醒告诉用户这么做会加快电量消耗。 一般应用在这一块被拒的原因有以下几种： 应用根本不需要定位功能。 应用需要定位功能，但是只需要短暂的获取少数的用户的位置，比如美团，新闻类的应用需要获得当前用户的所在城市，却使用了后台定位模式。 应用确实需要使用后台定位，比如打车类软件，但是应用中却没有任何界面展示这些定位数据。 解决方案： 如果你的应用根本不需要定位功能，但是还是在 info.plist 里面添加了 location in the UIBackgroundModes key ，那么在 plist 文件里面移除 UIBackgroundModes key 就可以，这中情况较少，新手小白会犯这种错误。 如果只是简单获取位置不需要使用后台定位，只需要去掉info.plist 的文件中的 UIBackgroundModes 即可。 这种情况比较复杂，推荐的做法是通过表格或者轨迹展示出后台定位的数据，再提交审核的时候告诉苹果那个功能需要后台定位，具体展示后台定位的 数据在那个界面,最后需要 Continued use of GPS running in the background can dramatically decrease battery life加到 App 描述里 面，可以参考滴滴出行的描述，否则也会被拒绝。 7. 问题：info.plist 权限配置被拒 iOS 10 之后如果需要调用相机，蓝牙等设备时，需要在 info.plist 文件中进行相应的配置，否则应用会直接崩溃，在 iOS 10 之前则是无法访问。另外，如果在 info.plist 中调用了配置了权限在应用中却没有使用到也是会被拒的。 解决方案： 一定要注意自己的 App 在使用中用到了哪些权限，不要添加无用的权限，也不要缺少必要的权限。 问题：应用提示更新被拒 应用内不能有任何提示更新应用的字样，且应用的更新只能通过 AppStore。因为苹果对于应用的更新有自己的一套策略，所以禁止应用本身提供更新方式，只要应用内出现。 解决方案： 如果不是很必要的话，尽量将应用内涉及到应用更新的部分去掉。如果真的需要使用应用更新，推荐的方法是应用启动的时候获取下应用在 AppStore 上面的版本号，与自己的版本号进行比较，当自己的版本号小于 AppStore 上面的版本号时，提示更新，否则的话不显示更新相关的内容。 问题：夺宝（抽奖）类应用被拒 根据 AppStore 审核准则 20.4 的规定，抽奖卷或抽奖参与权的购买，不论是透过第三方支付渠道或者余额扣款实现，都不能够在 app 内执行。 解决方案： 卓易夺宝 App 上架过程中遇到的问题，最后的解决方法是在审核过程中，所有的支付行为都跳转到 Safari 浏览器上面进行，审核完成后再使用支付宝等 app 平台支付。 问题：隐私条款问题被拒 在未获得用户事先允许，或未告知用户信息将被如何，在哪里使用的情况下，应用不可以传输用户数据。 解决方案： 《网站服务协议》《隐私条款》这些都不要少，注册时候让用户可勾选。另外注明需要的用户信息用来做什么。 问题：未提供测试账号被拒 如果应用中有需要用到账号或者其他资源的（例如：一个二维码）才能使用的一些功能，但未提供给苹果，可能会被拒绝上架。原因是苹果审核人员无法测试这些功能。 解决方案： 提供一个有效的测试帐号以及登录信息，并提供测试功能必要的的硬件和资源（例如，一个测试用的二维码） 问题：未通过 HTTPS 访问被拒 App Transport Security（ATS） 是 Apple 为增强 iOS App 网络通信安全提出的安全功能，适用于 iOS App 和 App Extension；在启用 ATS 之后，它会强制应用通过 HTTPS（而不是 HTTP ）连接网络服务。 WWDC 2016上提出，2016年底或2017年初，具体时间未定。App Store 上架审核加强对 ATS 配置的 review，即强制应用必须通过 HTTPS 连接网络服务，而不是随手将 NSAllowsArbitraryLoads 置为 YES，否则审核不予通过。 解决方案: ATS 的提出，是为了在系统层面保障 iOS APP 网络通信的安全；Apple 只所以加强对 ATS 配置的审核，是为了防止开发者们遇到ATS相关的场景时，只是简单地将 ATS完全关闭（只要没有强制性措施，开发者会这么做）；在此基础上，App 审核同样会遵循原则：App Review will require "reasonable justification" for most ATS exceptions。 Apple 官方给出的可以通过审核的声明 demo 如下： 必须使用第三方提供的服务，但是其没有支持 HTTPS； 必须通过域名连接到设备，但该设备不能支持安全连接； 必须展示不同来源的网页内容，但是不能基于 NSAllowsArbitraryLoadsInWebContent 支持的类（UIWebView / WKWebView）实现； 载入加密的媒体资源并且其中不涉及个人信息。 由于 Apple 官方并没有给出 ATS 审核的完整说明，ATS 审核时什么才是合适合理的声明也没有明确的客观定义，以上 demo 描述仅能作为参照。 参考文章： http://www.jianshu.com/p/b1b77d804254 https://github.com/wg689/Solve-App-Store-Review-Problem 22人点赞 iOS 作者：Jon1993 链接：https://www.jianshu.com/p/a992c88087a5 来源：简书

ECS磁盘 我想在ECS 跨服务器进行数据拷贝，有没有知道实现方法的？ Linux系统服务器重启或初始化系统之后，再登录服务器执行df -h查看磁盘挂载，发现数据不见了。这是为什么？能不能找回来？ 重启服务器后发现/alidata目录所有数据丢失。怎么才能找回来呢？ ECS Linux扩容格式化磁盘提示magic number in super-block while trying to open /dev/xvdb1 ？ Linux 实例初始化系统盘后，怎样才能重新挂载数据盘？ 如何在ECS 利用快照创建磁盘实现无损扩容数据盘？ ECS云服务器磁盘FAQ云服务器磁盘I/O速度是多少？ Linux 购买了数据盘，但是系统中看不到怎么办？ ECS系统盘和数据盘二次分区FAQ，系统盘能否再次划分出一个分区用作数据存储？ ECS系统盘和数据盘二次分区FAQ，数据盘能否再次划分出一个分区用作数据存储？ ECS系统盘和数据盘二次分区FAQ，划分了多个分区的磁盘，做快照时是针对该分区的，还是针对磁盘的？ ECS系统盘和数据盘二次分区FAQ，磁盘二次分区有哪些注意事项？ ECS系统盘和数据盘二次分区FAQ，数据盘进行二次分区后，此时回滚快照后，数据盘是几个分区？ 什么是可用区？ 怎么根据服务器应用需求选择可用区？ 按量付费云盘和云盘有什么区别？ 按量付费云盘和普通云盘的性能和数据安全性一样吗，磁盘性能会有提升吗? 可以使用用户快照创建按量付费云盘吗？ 什么是挂载点？ 一块按量付费云盘可以挂载到多个 ECS 实例上吗？ 一台 ECS 实例能同时挂载多少块按量付费云盘吗？ 按量付费云盘能够挂载到包年包月和按量付费 ECS 实例上吗？ 为什么挂载按量付费云盘时找不到我想挂载的 ECS 实例？ 购买按量付费云盘后，挂载到目标 ECS 实例的挂载点是否还需要执行磁盘挂载操作？ 我已经操作过续费变配，在续费变配期内是否还能将普通云盘转为按量付费云盘？ ECS快照 为什么我的按量付费云盘没有自动快照了？ 重新初始化磁盘时，我的快照会丢失吗？ 更换系统盘时，我的快照会丢失吗？ 卸载按量付费云盘时，我的磁盘会丢数据吗？ 我能够卸载系统盘吗？ 什么是独立云磁盘？ 什么是可用区？ 独立云磁盘跟现在的磁盘有什么区别？ 服务器应用与可用区选择的选择关系是怎么样的？ 独立云磁盘怎么收费？ 独立云磁盘能够挂载到包年包月实例上吗？ 独立云磁盘和普通云磁盘的磁盘性能和数据安全性一样吗，磁盘性能会有提升吗? 我的包年包月实例上不需要的磁盘能不能卸载？ 为什么我的独立云磁盘和我的实例一起释放了？ 为什么独立云磁盘挂载时找不到我想挂载的实例？ 为什么我在本实例列表中选择独立云磁盘挂载时找不到我想要挂载的磁盘？ 我删除磁盘的时候，快照会被保留吗？ 为什么我的独立云磁盘没有自动快照了？ 为什么我不能购买独立云磁盘？ 一台实例能挂载多少块独立云磁盘？ 卸载独立云磁盘时，我的磁盘会丢数据吗？ 我的系统盘能够卸载吗？ 什么是设备名？ 为什么我在控制台上找不到重置磁盘，更换操作系统，回滚快照的操作了？ 重新初始化磁盘时，我的快照会丢失吗？ 更换系统盘时，我的快照会丢失吗？ 为什么我的数据盘不能选择临时磁盘 独立云磁盘服务器的应用场景有哪些？ 可以使用用户快照创建独立云磁盘吗？ 独立云磁盘购买后挂载到目标实例的挂载点后，是否还需要执行磁盘挂载操作？ 本地SSD盘“本地”是指？ 本地SSD盘适合的用户场景有哪些？ SSD盘相对之前的普通云盘性能提升多少，是否可以提供具体参数？ 本地SSD盘是否支持在原ECS上进行添加或者将原云磁盘更换成本地SSD盘？ 本地SSD盘购买后是否支持升级？ SSD 云盘具备怎样的 I/O 性能？ SSD云盘的数据可靠性是怎样的？ SSD 云盘适合的应用场景有哪些？ SSD 云盘相对普通云盘性能提升多少？是否可以提供具体参数？ I/O 优化是什么概念？能将存量的 ECS 实例升级为 I/O 优化的实例吗？ 是否支持将原普通云盘更换成 SSD 云盘？ 如何购买 SSD 云盘，I/O 优化的实例及 SSD 云盘的价格是多少？ 为什么 I/O 优化的实例有时启动比较耗时？ 有些自定义镜像不支持创建 I/O 优化的实例，我该如何操作？ 购买SSD云盘后是否支持升级？ 使用了 I/O 优化实例和 SSD 云盘之后，Linux 系统在分区挂载的时候报错。 为什么我用 fio 测试性能时，会导致实例宕机？ 云盘参数和性能测试工具及方法有推荐的吗？ 我想扩容系统盘，求详细步骤！ 所有块存储都支持系统盘扩容吗？有地域限制吗？ 包年包月和按量付费的ECS实例都支持系统盘扩容吗？ 新购ECS时，系统盘开始单独收费？老用户存量的系统盘如何收费？ 新购ECS时，系统盘开始单独收费？老用户存量的系统盘如何收费？系统盘扩容是否需要停机操作？ 系统盘扩容上线后，系统盘的容量范围多少？ 哪些镜像支持系统盘扩容？ 云服务器续费变配后，不支持更换系统盘时指定系统盘容量？ 系统盘扩容之后是否支持再缩容？ 扩容系统盘应注意的问题？ 回滚磁盘报错，进行快照回滚的时候，出现如下错误提示： 执行回滚磁盘需要停止实例，并确保当前磁盘没有创建中的快照和没有更换过操作系统。 这是什么原因？ 普通云盘和SSD云盘添加挂载信息时有哪些要注意的事项？ 申请公测资格 什么是共享块存储？ 共享块存储适用于哪些行业和业务场景？ 为什么需要共享块存储？ 如何正确使用共享块存储？ 我能跨地域挂载共享块存储吗？ 共享块存储产品规格有哪些？ 我想知道阿里云产品的售卖模式和公测范围！ 公测购买入口是哪，求链接！ 有没有谁分享下共享块存储性能测试命令？ 数据盘挂载问题导致数据无法访问，我要怎么排查问题？ 我要怎样才能在Linux和Windows主机之间挂载ntfs格式云盘？ 为什么ECS实例里文件系统和快照空间大小不一致？在ECS实例内删除文件后再打快照，发现快照容量并没有变小。 ECS实例如何优化快照使用成本？ 在ECS实例里什么是快照商业化？ 在ECS实例里，快照商业化后过渡优惠期是什么时候？ 在ECS实例里，快照商业化的用户范围包括有哪些？ 在ECS实例里，如果我已经开通了 OSS，快照会自动存到我的 OSS Bucket 吗？是否需要重新再创建一个 Bucket 来存储快照？ 已经购买了 OSS 预付费存储包，同时在使用快照和 OSS 服务，那么存储包会优先抵扣哪个产品？ 快照商业化之后，我希望继续使用，需要购买哪个产品，云盘还是对象存储OSS资源包？ 快照商业化的收费模式是怎样的？ 快照费用的计算方法是怎样的？ 快照收费后，不停止自动快照是否就开始收取费用？ 快照要收费了，之前的快照要被删除吗？ 如果不想付费，之前的快照能继续使用吗？ 快照收费后，之前创建的手动快照和自动快照都会收费吗？ 快照收费前停止快照策略，需手动删除历史快照吗？正式收费后会直接删除我的历史快照吗？ 快照收费以后，账户欠费对快照有什么影响？ 如果账号欠费，有关联关系（创建过磁盘或者镜像）的快照，在欠费15天之后是否会被删除？ 快照服务和块存储服务的关系，在收费方面的关系是什么？ 快照容量是如何计算的，是等于磁盘大小吗？ ECS实例内删除文件会减少空间占用吗？ 为什么快照容量大于文件系统内看到的数据量？ 参考快照增量说明，如中间快照被删除，后面的快照能否使用？ 如何开通快照服务？ 快照和镜像的关系？ 如何在保留关联实例和磁盘的情况下，删除快照跟镜像，快照、实例、镜像之间的关系？ 快照和块存储、OSS对象存储是什么关系？ 一块云盘能否设置多个快照策略？ 快照 2.0 服务包括哪些内容？ 快照有什么用途？ 快照 2.0 服务支持的云盘类型？ 快照数量有什么限制？ 快照保留时长怎样？ 打快照对块存储 I/O 性能有多少影响？ 快照怎么收费？ 老的自动快照策略什么时候不可用？ 老的快照策略产生的快照什么时候删除？ 自动快照功能细节有哪些？ 用户的自定义快照和自动快照有冲突吗？ 我能保留其中想要的自动快照而让系统不删除吗？ 如果一个自动快照被引用（用户创建自定义镜像或者磁盘），会导致自动快照策略执行失败吗？ 我如果什么都没有设置，自动快照会启动吗？ 自动快照能够删除吗？ 自动快照具体在什么时间创建能看到吗？ 我如何区分哪些快照是自动快照和用户快照？ 更换系统盘、云服务器 ECS 到期后或手动释放磁盘时，自动快照会不会释放？ 未随磁盘释放和更换系统盘释放的自动快照会一直保留吗？ 云服务器 ECS 到期后或手动释放磁盘时，手工快照会不会释放？ 我能单独制定某几块磁盘执行或取消自动快照吗？ 云服务器 ECS 有没有自动备份？ 磁盘无快照是否能够回滚或数据恢复？ 快照回滚能否单独回滚某个分区或部分数据？ 系统盘快照回滚是否会影响数据盘？ 更换系统后，快照能否回滚？ 在回滚快照前，有哪些注意事项？ 怎样使ECS回滚快照后同步数据？ 如何通过API配置定时自定义快照？ 超出预付费存储包的流量，会怎么收费？ ECS镜像 Aliyun Linux 17.01 特性有哪些，有说明文档吗？ 云市场镜像有哪些功能？ 镜像能带来哪些便利？ 目前镜像支持哪些服务器环境和应用场景？ 镜像是否安全？ 选择了镜像后能更换吗？ 镜像安装使用过程中出问题了怎么办？ Docker私有镜像库是什么？ 自定义镜像如何查看数据盘？ 自定义镜像，如何卸载和删除 disk table 里的数据？ 如何确认已经卸载数据盘，并可以新建自定义镜像？ ECS 实例释放后，自定义镜像是否还存在？ ECS 实例释放后，快照是否还存在？ 用于创建自定义镜像的云服务器 ECS 实例到期或释放数据后，创建的自定义镜像是否受影响？使用自定义镜像开通的云服务器 ECS 实例是否受影响？ 使用自定义镜像创建的 ECS 实例是否可以更换操作系统？更换系统后原来的自定义镜像是否还可以使用？ 更换系统盘时另选操作系统，是否可以使用自定义镜像？ 已创建的自定义镜像，是否可以用于更换另一台云服务器 ECS 的系统盘数据？ 是否可以升级自定义镜像开通的云服务器 ECS 的 CPU、内存、带宽、硬盘等？ 是否可以跨地域使用自定义镜像？ 包年包月云服务器 ECS 的自定义镜像，是否可以用于开通按量付费的云服务器 ECS？ ECS Windows企业版和标准版区别 什么情况下需要复制镜像？ 可以复制哪些镜像？ 当前有哪些支持镜像复制功能的地域？ 复制一个镜像大概需要多久？ 复制镜像怎么收费的？ 在复制镜像过程中，源镜像和目标镜像有什么限制？ 怎么复制我的云账号的镜像资源到其他云账号的其他地域？ 复制镜像有镜像容量限制吗？ 如何购买镜像市场镜像？ 按次购买的镜像的使用期限是多久？ 镜像市场的镜像支持退款吗？ 镜像市场商业化后，还有免费的镜像市场镜像吗？ 在杭州买了一个镜像市场的镜像，能否在北京创建ECS实例或者更换系统盘？ ECS实例使用镜像市场的镜像，升级和续费ECS实例，需要为镜像继续付费吗？ ECS实例使用镜像市场的镜像，实例释放后，继续购买ECS实例还可以免费使用该镜像吗？ 使用镜像市场镜像创建ECS实例，该实例创建一个自定义镜像，使用该自定义镜像创建ECS实例需要为该镜像付费吗？ 来源于镜像市场的镜像复制到其他地域创建ECS实例，是否需要为该镜像付费？ 如果把来源于镜像市场的自定义镜像共享给其他账号（B）创建ECS实例，账号B是否需要为该镜像付费？ 如果使用镜像市场的镜像或者来源于镜像市场的镜像进行更换系统盘，需要付费吗？ ECS实例正在使用镜像市场的镜像，进行重置系统盘需要收费吗？ 怎么调用ECS API，使用镜像市场镜像或者来源镜像市场的自定义镜像或者共享镜像，创建ECS实例和更换系统盘？ 如果没有购买镜像市场的镜像或者来源于镜像市场的镜像，在调用ECS API 使用该镜像创建ECS实例和更换系统盘，会报错吗？ 我的ESS是自动创建机器的，并且量是不固定，设置最小值为10台，最大值为100台，那么使用镜像市场的镜像如何保证我的的需求实例能正常弹出来？ 镜像市场的镜像是否支持批量购买？ 如果之前使用的镜像市场的镜像，已不存在该商品（如：jxsc000010、jxsc000019），怎能保证已经设置的弹性伸缩组的机器的正常弹出？ 1个product code能否支持不同region的镜像？ 我买了100 product code同样值的镜像，是否可以支持在所有的地域可用？ 为什么有的ECS云服务器无法选择Windows操作系统？ 操作系统是否要收费？ 我能否自己安装或者升级操作系统？ 服务器的登录用户名密码是什么？ 能否更换或升级操作系统？ 操作系统是否有图形界面？ 如何选择操作系统？ 操作系统自带 FTP 上传吗？ 每个用户最多可以获得多少个共享镜像？ 每个镜像最多可以共享给多少个用户？ 使用共享镜像是否占用我的镜像名额？ 使用共享镜像创建实例的时候存不存在地域限制？ 我曾把自己账号中的某个自定义镜像共享给其他账号，现在我可以删除这个镜像吗 我把某个自定义镜像（M）的共享账号（A）给删除了，会有什么影响？ 使用共享镜像创建实例存在什么样的风险？ 我把自定义镜像共享给其他账号，存在什么风险？ 我能把别人共享给我的镜像再共享给他人吗？ 我把镜像共享给他人，还能使用该镜像创建实例吗？ ECS Windows服务器桌面分辨率过高导致VNC花屏处理方法通过 管理终端 进入服务器后，把 Windows 服务器桌面分辨率设置过高，确定后，WebVNC 出现花屏。 ECS创建自定义镜像创建服务器为何需要注释挂载项 勾选"IO优化实例"选项导致购买ECS实例时无法选择云市场镜像 如何为 Linux 服务器安装 GRUB 历史Linux镜像的问题修复方案 如何处理 CentOS DNS 解析超时? 什么是镜像市场的包年包月和按周付费镜像？ 预付费镜像能与哪种 ECS 实例搭配使用？ 怎么购买预付费镜像？可以单独购买吗？ 预付费镜像怎么付费？ 预付费镜像到期了就不能用了吗？怎么继续使用？ 购买预付费镜像后，如果我不想再使用这个镜像，能要求退款吗？ 退款时，费用怎么结算？ 预付费镜像能转换为按量付费镜像吗？ 预付费镜像与其它镜像之间能互换吗？更换后费用怎么计算？ 在哪里查看并管理我购买的预付费镜像？ 使用预付费镜像制作的自定义镜像会收费吗？预付费镜像过期对于自定义镜像有什么影响？ ECS 实例操作系统选择说明 阿里云支持哪些 SUSE 版本？ SUSE 操作系统提供哪些服务支持？ ECS安全组 如何检查 TCP 80 端口是否正常工作？ 什么是安全组？ 为什么在购买 ECS 实例的时候选择安全组？ 安全组配置错误会造成哪些影响？ 专有网络实例设置安全组规则时为什么不能设置公网规则？ 创建 ECS 实例时我还没创建安全组怎么办？ 为什么无法访问 25 端口？ 为什么我的安全组里自动添加了很多规则？ 为什么有些安全组规则的优先级是 110？ 为什么我在安全组里放行了 TCP 80 端口，还是无法访问 80 端口？ ECS安全组被添加内网ip地址了，是怎么回事？ 能说明下ECS安全组中规则的优先级执行匹配顺序吗？ ECS实例安全组默认的公网规则被删除导致无法ping通，ECS 服务器无法ping通，排查防火墙、网卡IP配置无误，回滚系统后仍然无法ping通。 我刚购买了ECS实例，如何选择及配置安全组？ 没有添加默认安全组访问规则-导致通过API创建的ECS实例断网，要怎么恢复？ 使用ECS安全组工具撤销之前账号间互通的操作 ECS网络 带宽与上传、下载速度峰值的有什么关系？ 弹性公网IP在哪里可以查看流量和带宽监控信息？ 我用的是ECS Ubuntu系统，要怎么单独禁用和启动内外网卡？ ECS 实例子网划分和掩码是什么？ ECS 实例网络带宽是否独享？ 带宽单线还是双线，电信还是网通？ 5 Mbps 带宽怎么理解？ 带宽的价格是多少？ 不同地域的 ECS 实例之间的内网是通的吗？ 为何新建的 ECS 实例就有 200 Kbps 左右入网流量？ 我的 ECS 实例经常能在 Web 日志中看到大量的恶意 IP 访问我的网站，疑有刷流量和恶意访问的嫌疑，询问云盾是否有屏蔽 IP 的功能？ 包月ECS新购时是否可以选择带宽按照使用流量计费？ 包月ECS带宽按流量计费是如何计费的? 目前使用的固定带宽计费，是否可以转换为带宽按流量计费？ 是否可以随时调整流量带宽峰值？ 续费变更配置时（比如到期时间为2015年3月31日，续费一个月到4月30日），如果将包月ECS按固定带宽计费改成按流量付费计费，操作以后在未生效前（3月31日前），是否还可以升级带宽？ 续费变更配置时候将包月ECS带宽按流量计费改成按固定带宽计费，为什么我的带宽服务停掉了？ 如果账号没有足够余额，欠费怎么办？ECS实例也会停掉吗？ 带宽流量欠费是否有短信通知？ 当带宽按照流量计费欠费时，是否可以对实例进行升级 CPU、内存操作？ 欠费充值后带宽是自动恢复的吗？ 包月带宽转流量计费后，流量价格是多少？ ECS 服务器出现了异地登录怎么办？ 爱哪里可以查看云服务器 ECS 公网流量统计总和？ 我的ECS 实例对外 DDoS 攻击导致被锁定了，要如何处理 ？ 什么是云服务器 ECS 的入网带宽和出网带宽？ ECS云服务器如何禁用公网IP？ ECS 实例停止（关机）后按量付费带宽仍产生流量，ECS 实例在控制台上状态为已停止，但按量付费的带宽每小时仍会产生不小的费用，且此时 ECS 实例正在遭受攻击，云盾控制台中 DDoS 防护中 ECS 的状态为清洗中。 访问ECS服务器的网站提示“由于你访问的URL可能对网站造成安全威胁，您的访问被阻断”，这是什么原因？ 服务器黑洞是什么？求科普！ 如果想确认该服务器的IP信息和地理位置，要在哪里去查询？ 我想知道客户端本地到ECS服务器是不是丢包，要怎么测试？ 内网和公共 NTP 服务器是什么？它们两个有什么区别 我能 ping 通但端口不通，这是端口的问题吗？ 如何通过防火墙策略限制对外扫描行为？ 我想用手机移动端网络路由跟踪探测，可以吗？ 云监控中的ECS带宽和ECS控制台中看到的带宽不一致是什么原因？ 云服务器ECS三张网卡有什么区别？ Ubuntu系统ECS使用“如何通过防火墙策略限制对外扫描行为”脚本之后出现无法远程、数据库连接不上。 什么业务场景需要在专有网络(VPC)类型ECS购买PublicIP？ 怎么购买专有网络(VPC)类型分配 PublicIP 的 ECS？ 专有网络(VPC)类型 ECS 的 PublicIP 和 EIP 的区别？ 专有网络(VPC)类型ECS的 PublicIP 的可以升级带宽吗？ 专有网络(VPC)类型ECS的 PublicIP 可以解绑吗？ 如果购买网络(VPC)类型 ECS 的时候，没有分配公网 IP，该怎么才能分配一个公网 IP？ 怎么查询专有网络(VPC)类型 ECS 的 PublicIP 的监控数据？ 怎么查询专有网络(VPC)类型ECS的按流量付费的 PublicIP 的账单？ 专有网络和经典网络的 PublicIP 异同？ 专有网络(VPC)类型 ECS 购买 PublicIP 的付费方式？ ECS API 如何通过 API / SDK 实现不同账号 ECS 实例的内网通信？ ECS API绑定公网IP报错：The IP is already in use分析 ECS API修改实例带宽不能指定时间范围吗？ 所在可用区不支持相应磁盘类型-导致ECS API创建实例报错 用ECS API创建实例的时候，返回如下错误信息： "Code": "InvalidDataDiskCategory.NotSupported" 如何创建有公网 IP 的 ECS 实例？ 通过API或SDK查询安全组规则无法显示所有的规则，这是怎么回事？ 如何通过OpenAPI创建ECS实例的流程状态描述？ 数据传输服务DTS实时同步功能，我想只同步表结构，要怎么做？ 如何获取控制台RequestId？ 阿里云中国站部分地域实例什么时候降价？ ECS Linux 实例怎么设置 Locale 变量？ 克隆ECS服务器的方法 其它国家和地区是否都可以提供经典网络和专有网络的类型呢？网络类型是否可以变更呢？ 各个地域的网络覆盖范围是什么呢？ 其他相关问题 不同地域的实例，价格一样吗？ 如果我使用其它国家和地区的实例搭建了一个网站，我的用户将通过域名访问网站，这个域名需要 ICP 备案吗？ 为什么有些实例规格只能在中国大陆地域购买，而在其它国家和地区无法购买？ 可否将中国大陆地域的实例迁移到其它国家和地区呢？ 如何在其它国家和地区部署 ECS 实例？ 我要买其它国家和地区的实例，需要单独申请一个国际站账号吗？ ——更多ECS相关问题—— · ECS故障处理百问合集

详细解答可以参考官方帮助文档 发送访问OSS的请求 您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下： 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner，也称为开发者。第三方用户是指访问Bucket里资源的用户。 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说，如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。 AccessKey 类型 目前访问 OSS 使用的 AK（AccessKey）有三种类型，具体如下： 阿里云账号AccessKey 阿里云账号AK特指Bucket拥有者的AK，每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对（AccessKeyId和AccessKeySecret）。 用户可以登录AccessKey管理控制台，申请新增或删除AK对。 每个AK对都有active/inactive两种状态。 Active 表明用户的 AK 处于激活状态，可以在身份验证的时候使用。 Inactive 表明用户的 AK 处于非激活状态，不能在身份验证的时候使用。 说明 请避免直接使用阿里云账户的 AccessKey。 RAM子账号AccessKey RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM，您可以集中管理您的用户（比如员工、系统或应用程序），以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的，并且这些账号下不能拥有实际的任何资源，所有资源都属于主账号。 STS账号AccessKey STS（Security Token Service）是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。 身份验证具体实现 目前主要有三种身份验证方式： AK验证 RAM验证 STS验证 当用户以个人身份向OSS发送请求时，其身份验证的实现如下： 用户将发送的请求按照OSS指定的格式生成签名字符串。 用户使用AccessKeySecret对签名字符串进行加密产生验证码。 OSS收到请求以后，通过AccessKeyId找到对应的AccessKeySecret，以同样的方法提取签名字符串和验证码。 如果计算出来的验证码和提供的一样即认为该请求是有效的。 否则，OSS将拒绝处理这次请求，并返回HTTP 403错误。 对于用户来说可以直接使用OSS提供的SDK，配合不同类型的AccessKey即可实现不同的身份验证。 权限控制 针对存放在Bucket的Object的访问，OSS提供了多种权限控制，主要有： Bucket级别权限 Object级别权限 账号级别权限（RAM） 临时账号权限（STS） Bucket级别权限 Bucket权限类型 OSS提供ACL（Access Control List）权限控制方法，OSS ACL提供Bucket级别的权限访问控制，Bucket目前有三种访问权限：public-read-write，public-read和private，它们的含义如下： 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 任何人（包括匿名访问）都可以对该Bucket中的Object进行读/写/删除操作；所有这些操作产生的费用由该Bucket的Owner承担，请慎用该权限。 public-read 公共读，私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作；任何人（包括匿名访问）可以对Object进行读操作。 private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作；其他人在未经授权的情况下无法访问该Bucket内的Object。 Bucket权限设定和读取方法 功能使用参考： API：Put BucketACL SDK：Java SDK-设置Bucket ACL 控制台：创建Bucket权限设置 API：Get BucketACL SDK：Java SDK-获取Bucket ACL Object级别权限 Object权限类型 OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限：private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置，这个操作只有Bucket Owner有权限执行。 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 该ACL表明某个Object是公共读写资源，即所有用户拥有对该Object的读写权限。 public-read 公共读，私有写 该ACL表明某个Object是公共读资源，即非Object Owner只有该Object的读权限，而Object Owner拥有该Object的读写权限。 private 私有读写 该ACL表明某个Object是私有资源，即只有该Object的Owner拥有该Object的读写权限，其他的用户没有权限操作该Object。 default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源，即Bucket是什么权限，Object就是什么权限。 说明 如果没有设置Object的权限，即Object的ACL为default，Object的权限和Bucket权限一致。 如果设置了Object的权限，Object的权限大于Bucket权限。举个例子，如果设置了Object的权限是public-read，无论Bucket是什么权限，该Object都可以被身份验证访问和匿名访问。 Object权限设定和读取方法 功能使用参考： API：Put Object ACL SDK：Java SDK-ObjectACL 中设定Object ACL API：Get Object ACL SDK：Java SDK-ObjectACL 中读取Object ACL 账号级别权限（RAM） 使用场景 如果您购买了云资源，您的组织里有多个用户需要使用这些云资源，这些用户只能共享使用您的云账号AccessKey。这里有两个问题： 您的密钥由多人共享，泄露的风险很高。 您无法控制特定用户能访问哪些资源（比如Bucket）的权限。 解决方法：在您的阿里云账号下面，通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号，创建出来的账号被称为子账号，使用子账号的AccessKey只能使用主账号授权的操作和资源。 具体实现 有关RAM详情，请参考RAM用户手册。 对于授权中需要的Policy的配置方式可以参考本章最后一节：RAM和STS授权策略（Policy）配置。 临时账号权限（STS） 使用场景 对于您本地身份系统所管理的用户，比如您的App的用户、您的企业本地账号、第三方App，也有直接访问OSS资源的可能，将这部分用户称为联盟用户。此外，用户还可以是您创建的能访问您的阿里云资源的应用程序。 对于这部分联盟用户，通过阿里云STS (Security Token Service) 服务为阿里云账号（或RAM用户）提供短期访问权限管理。您不需要透露云账号（或RAM用户）的长期密钥（如登录密码、AccessKey），只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题，访问凭证过期后会自动失效。 用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。 具体实现 STS安全令牌、角色管理和使用相关内容详情，请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可，也可以直接使用STS SDK来调用该方法。 RAM和STS应用场景实践 对于不同的应用场景，涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。 以一个移动App举例。假设您是一个移动App开发者，打算使用阿里云OSS服务来保存App的终端用户数据，并且要保证每个App用户之间的数据隔离，防止一个App用户获取到其它App用户的数据。 方式一：使用AppServer来做数据中转和数据隔离如上图所示，您需要开发一个AppServer。只有AppServer能访问云服务，ClientApp的每次读写数据都需要通过AppServer，AppServer来保证不同用户数据的隔离访问。 对于该种使用方式，使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号（主账号）的密钥访问OSS，避免出现安全问题。 方式二：使用STS让用户直接访问OSS STS方案描述如下图所示：方案的详细描述如下： App用户登录。App用户和云账号无关，它是App的终端用户，AppServer支持App用户登录。对于每个有效的App用户来说，需要AppServer能定义出每个App用户的最小访问权限。 AppServer请求STS服务获取一个安全令牌（SecurityToken）。在调用STS之前，AppServer需要确定App用户的最小访问权限（用Policy语法描述）以及授权的过期时间。然后通过扮演角色（AssumeRole）来获取一个代表角色身份的安全令牌。 STS返回给AppServer一个有效的访问凭证，包括一个安全令牌（SecurityToken）、临时访问密钥（AccessKeyId, AccessKeySecret）以及过期时间。 AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时，ClientApp需要向AppServer申请新的有效访问凭证。比如，访问凭证有效期为1小时，那么ClientApp可以每30分钟向AppServer请求更新访问凭证。 ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证，并会依赖STS服务来验证访问凭证，正确响应用户请求。 RAM和STS授权策略（Policy）配置 对于RAM或者STS授权中使用Policy，详细规则如下。 示例 先看下面的一个Policy示例： { "Version": "1", "Statement": [ { "Action": [ "oss:GetBucketAcl", "oss:ListObjects" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket" ], "Effect": "Allow", "Condition": { "StringEquals": { "acs:UserAgent": "java-sdk", "oss:Prefix": "foo" }, "IpAddress": { "acs:SourceIp": "192.168.0.1" } } }, { "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket/file*" ], "Effect": "Allow", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.0.1" } } } ] } 这是一个授权的Policy，用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement（一条Policy当中可以有多条Statement）。Statement里面规定了相应的Action、Resource、Effect和Condition。 这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户，并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk，源IP为192.168.0.1的时候鉴权才能通过，被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket（ListObjects）的时候起作用的，关于这个字段的解释详见OSS的API文档。 配置细则 Version Version定义了Policy的版本，本文档中sw2q的配置方式，设置为1。 Statement 通过Statement描述授权语义，其中可以根据业务场景包含多条语义，每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查，所有匹配成功的Statement会根据Effect的设置不同分为通过（Allow）、禁止（Deny），其中禁止（Deny）的优先。如果匹配成功的都为通过，该条请求即鉴权通过。如果匹配成功有一条禁止，或者没有任何条目匹配成功，该条请求被禁止访问。 Action Action分为三大类：Service级别操作，对应的是GetService操作，用来列出所有属于该用户的Bucket列表。 Bucket级别操作，对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作，操作的对象是Bucket，它们的名称和相应的接口名称一一对应。 Object级别操作，分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload，操作对象是Object。 如想授权某一类的Object的操作，可以选择这几种的一种或几种。另外，所有的Action前面都必须加上oss:，如上面例子所示。Action是一个列表，可以有多个Action。具体的Action和API接口的对应关系如下： Service级别 API Action GetService（ListBuckets） oss:ListBuckets Bucket级别 API Action PutBucket oss:PutBucket GetBucket（ListObjects） oss:ListObjects PutBucketAcl oss:PutBucketAcl DeleteBucket oss:DeleteBucket GetBucketLocation oss:GetBucketLocation GetBucketAcl oss:GetBucketAcl GetBucketLogging oss:GetBucketLogging PutBucketLogging oss:PutBucketLogging DeleteBucketLogging oss:DeleteBucketLogging GetBucketWebsite oss:GetBucketWebsite PutBucketWebsite oss:PutBucketWebsite DeleteBucketWebsite oss:DeleteBucketWebsite GetBucketReferer oss:GetBucketReferer PutBucketReferer oss:PutBucketReferer GetBucketLifecycle oss:GetBucketLifecycle PutBucketLifecycle oss:PutBucketLifecycle DeleteBucketLifecycle oss:DeleteBucketLifecycle ListMultipartUploads oss:ListMultipartUploads PutBucketCors oss:PutBucketCors GetBucketCors oss:GetBucketCors DeleteBucketCors oss:DeleteBucketCors PutBucketReplication oss:PutBucketReplication GetBucketReplication oss:GetBucketReplication DeleteBucketReplication oss:DeleteBucketReplication GetBucketReplicationLocation oss:GetBucketReplicationLocation GetBucketReplicationProgress oss:GetBucketReplicationProgress Object级别 API Action GetObject oss:GetObject HeadObject oss:GetObject PutObject oss:PutObject PostObject oss:PutObject InitiateMultipartUpload oss:PutObject UploadPart oss:PutObject CompleteMultipart oss:PutObject DeleteObject oss:DeleteObject DeleteMultipartObjects oss:DeleteObject AbortMultipartUpload oss:AbortMultipartUpload ListParts oss:ListParts CopyObject oss:GetObject,oss:PutObject UploadPartCopy oss:GetObject,oss:PutObject AppendObject oss:PutObject GetObjectAcl oss:GetObjectAcl PutObjectAcl oss:PutObjectAcl Resource Resource指代的是OSS上面的某个具体的资源或者某些资源（支持*通配），resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name}，即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表，可以有多个Resource。其中的region字段暂时不做支持，设置为*。 Effect Effect代表本条的Statement的授权的结果，分为Allow和Deny，分别指代通过和禁止。多条Statement同时匹配成功时，禁止（Deny）的优先级更高。 例如，期望禁止用户对某一目录进行删除，但对于其他文件有全部权限： { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:bucketname" ] }, { "Effect": "Deny", "Action": [ "oss:DeleteObject" ], "Resource": [ "acs:oss:*:*:bucketname/index/*", ] } ] } Condition Condition代表Policy授权的一些条件，上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。 OSS支持的Condition如下： condition 功能 合法取值 acs:SourceIp 指定ip网段 普通的ip，支持*通配 acs:UserAgent 指定http useragent头 字符串 acs:CurrentTime 指定合法的访问时间 ISO8601格式 acs:SecureTransport 是否是https协议 “true”或者”false” oss:Prefix 用作ListObjects时的prefix 合法的object name 更多示例 针对具体场景更多的授权策略配置示例，可以参考教程示例：控制存储空间和文件夹的访问权限和OSS授权常见问题。 Policy在线图形化便捷配置工具，请单击这里。 最佳实践 RAM和STS使用指南

详细解答可以参考官方帮助文档 发送访问OSS的请求 您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下： 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner，也称为开发者。第三方用户是指访问Bucket里资源的用户。 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说，如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。 AccessKey 类型 目前访问 OSS 使用的 AK（AccessKey）有三种类型，具体如下： 阿里云账号AccessKey 阿里云账号AK特指Bucket拥有者的AK，每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对（AccessKeyId和AccessKeySecret）。 用户可以登录AccessKey管理控制台，申请新增或删除AK对。 每个AK对都有active/inactive两种状态。 Active 表明用户的 AK 处于激活状态，可以在身份验证的时候使用。 Inactive 表明用户的 AK 处于非激活状态，不能在身份验证的时候使用。 说明 请避免直接使用阿里云账户的 AccessKey。 RAM子账号AccessKey RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM，您可以集中管理您的用户（比如员工、系统或应用程序），以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的，并且这些账号下不能拥有实际的任何资源，所有资源都属于主账号。 STS账号AccessKey STS（Security Token Service）是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。 身份验证具体实现 目前主要有三种身份验证方式： AK验证 RAM验证 STS验证 当用户以个人身份向OSS发送请求时，其身份验证的实现如下： 用户将发送的请求按照OSS指定的格式生成签名字符串。 用户使用AccessKeySecret对签名字符串进行加密产生验证码。 OSS收到请求以后，通过AccessKeyId找到对应的AccessKeySecret，以同样的方法提取签名字符串和验证码。 如果计算出来的验证码和提供的一样即认为该请求是有效的。 否则，OSS将拒绝处理这次请求，并返回HTTP 403错误。 对于用户来说可以直接使用OSS提供的SDK，配合不同类型的AccessKey即可实现不同的身份验证。 权限控制 针对存放在Bucket的Object的访问，OSS提供了多种权限控制，主要有： Bucket级别权限 Object级别权限 账号级别权限（RAM） 临时账号权限（STS） Bucket级别权限 Bucket权限类型 OSS提供ACL（Access Control List）权限控制方法，OSS ACL提供Bucket级别的权限访问控制，Bucket目前有三种访问权限：public-read-write，public-read和private，它们的含义如下： 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 任何人（包括匿名访问）都可以对该Bucket中的Object进行读/写/删除操作；所有这些操作产生的费用由该Bucket的Owner承担，请慎用该权限。 public-read 公共读，私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作；任何人（包括匿名访问）可以对Object进行读操作。 private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作；其他人在未经授权的情况下无法访问该Bucket内的Object。 Bucket权限设定和读取方法 功能使用参考： API：Put BucketACL SDK：Java SDK-设置Bucket ACL 控制台：创建Bucket权限设置 API：Get BucketACL SDK：Java SDK-获取Bucket ACL Object级别权限 Object权限类型 OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限：private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置，这个操作只有Bucket Owner有权限执行。 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 该ACL表明某个Object是公共读写资源，即所有用户拥有对该Object的读写权限。 public-read 公共读，私有写 该ACL表明某个Object是公共读资源，即非Object Owner只有该Object的读权限，而Object Owner拥有该Object的读写权限。 private 私有读写 该ACL表明某个Object是私有资源，即只有该Object的Owner拥有该Object的读写权限，其他的用户没有权限操作该Object。 default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源，即Bucket是什么权限，Object就是什么权限。 说明 如果没有设置Object的权限，即Object的ACL为default，Object的权限和Bucket权限一致。 如果设置了Object的权限，Object的权限大于Bucket权限。举个例子，如果设置了Object的权限是public-read，无论Bucket是什么权限，该Object都可以被身份验证访问和匿名访问。 Object权限设定和读取方法 功能使用参考： API：Put Object ACL SDK：Java SDK-ObjectACL 中设定Object ACL API：Get Object ACL SDK：Java SDK-ObjectACL 中读取Object ACL 账号级别权限（RAM） 使用场景 如果您购买了云资源，您的组织里有多个用户需要使用这些云资源，这些用户只能共享使用您的云账号AccessKey。这里有两个问题： 您的密钥由多人共享，泄露的风险很高。 您无法控制特定用户能访问哪些资源（比如Bucket）的权限。 解决方法：在您的阿里云账号下面，通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号，创建出来的账号被称为子账号，使用子账号的AccessKey只能使用主账号授权的操作和资源。 具体实现 有关RAM详情，请参考RAM用户手册。 对于授权中需要的Policy的配置方式可以参考本章最后一节：RAM和STS授权策略（Policy）配置。 临时账号权限（STS） 使用场景 对于您本地身份系统所管理的用户，比如您的App的用户、您的企业本地账号、第三方App，也有直接访问OSS资源的可能，将这部分用户称为联盟用户。此外，用户还可以是您创建的能访问您的阿里云资源的应用程序。 对于这部分联盟用户，通过阿里云STS (Security Token Service) 服务为阿里云账号（或RAM用户）提供短期访问权限管理。您不需要透露云账号（或RAM用户）的长期密钥（如登录密码、AccessKey），只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题，访问凭证过期后会自动失效。 用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。 具体实现 STS安全令牌、角色管理和使用相关内容详情，请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可，也可以直接使用STS SDK来调用该方法。 RAM和STS应用场景实践 对于不同的应用场景，涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。 以一个移动App举例。假设您是一个移动App开发者，打算使用阿里云OSS服务来保存App的终端用户数据，并且要保证每个App用户之间的数据隔离，防止一个App用户获取到其它App用户的数据。 方式一：使用AppServer来做数据中转和数据隔离如上图所示，您需要开发一个AppServer。只有AppServer能访问云服务，ClientApp的每次读写数据都需要通过AppServer，AppServer来保证不同用户数据的隔离访问。 对于该种使用方式，使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号（主账号）的密钥访问OSS，避免出现安全问题。 方式二：使用STS让用户直接访问OSS STS方案描述如下图所示：方案的详细描述如下： App用户登录。App用户和云账号无关，它是App的终端用户，AppServer支持App用户登录。对于每个有效的App用户来说，需要AppServer能定义出每个App用户的最小访问权限。 AppServer请求STS服务获取一个安全令牌（SecurityToken）。在调用STS之前，AppServer需要确定App用户的最小访问权限（用Policy语法描述）以及授权的过期时间。然后通过扮演角色（AssumeRole）来获取一个代表角色身份的安全令牌。 STS返回给AppServer一个有效的访问凭证，包括一个安全令牌（SecurityToken）、临时访问密钥（AccessKeyId, AccessKeySecret）以及过期时间。 AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时，ClientApp需要向AppServer申请新的有效访问凭证。比如，访问凭证有效期为1小时，那么ClientApp可以每30分钟向AppServer请求更新访问凭证。 ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证，并会依赖STS服务来验证访问凭证，正确响应用户请求。 RAM和STS授权策略（Policy）配置 对于RAM或者STS授权中使用Policy，详细规则如下。 示例 先看下面的一个Policy示例： { "Version": "1", "Statement": [ { "Action": [ "oss:GetBucketAcl", "oss:ListObjects" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket" ], "Effect": "Allow", "Condition": { "StringEquals": { "acs:UserAgent": "java-sdk", "oss:Prefix": "foo" }, "IpAddress": { "acs:SourceIp": "192.168.0.1" } } }, { "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket/file*" ], "Effect": "Allow", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.0.1" } } } ] } 这是一个授权的Policy，用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement（一条Policy当中可以有多条Statement）。Statement里面规定了相应的Action、Resource、Effect和Condition。 这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户，并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk，源IP为192.168.0.1的时候鉴权才能通过，被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket（ListObjects）的时候起作用的，关于这个字段的解释详见OSS的API文档。 配置细则 Version Version定义了Policy的版本，本文档中sw2q的配置方式，设置为1。 Statement 通过Statement描述授权语义，其中可以根据业务场景包含多条语义，每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查，所有匹配成功的Statement会根据Effect的设置不同分为通过（Allow）、禁止（Deny），其中禁止（Deny）的优先。如果匹配成功的都为通过，该条请求即鉴权通过。如果匹配成功有一条禁止，或者没有任何条目匹配成功，该条请求被禁止访问。 Action Action分为三大类：Service级别操作，对应的是GetService操作，用来列出所有属于该用户的Bucket列表。 Bucket级别操作，对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作，操作的对象是Bucket，它们的名称和相应的接口名称一一对应。 Object级别操作，分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload，操作对象是Object。 如想授权某一类的Object的操作，可以选择这几种的一种或几种。另外，所有的Action前面都必须加上oss:，如上面例子所示。Action是一个列表，可以有多个Action。具体的Action和API接口的对应关系如下： Service级别 API Action GetService（ListBuckets） oss:ListBuckets Bucket级别 API Action PutBucket oss:PutBucket GetBucket（ListObjects） oss:ListObjects PutBucketAcl oss:PutBucketAcl DeleteBucket oss:DeleteBucket GetBucketLocation oss:GetBucketLocation GetBucketAcl oss:GetBucketAcl GetBucketLogging oss:GetBucketLogging PutBucketLogging oss:PutBucketLogging DeleteBucketLogging oss:DeleteBucketLogging GetBucketWebsite oss:GetBucketWebsite PutBucketWebsite oss:PutBucketWebsite DeleteBucketWebsite oss:DeleteBucketWebsite GetBucketReferer oss:GetBucketReferer PutBucketReferer oss:PutBucketReferer GetBucketLifecycle oss:GetBucketLifecycle PutBucketLifecycle oss:PutBucketLifecycle DeleteBucketLifecycle oss:DeleteBucketLifecycle ListMultipartUploads oss:ListMultipartUploads PutBucketCors oss:PutBucketCors GetBucketCors oss:GetBucketCors DeleteBucketCors oss:DeleteBucketCors PutBucketReplication oss:PutBucketReplication GetBucketReplication oss:GetBucketReplication DeleteBucketReplication oss:DeleteBucketReplication GetBucketReplicationLocation oss:GetBucketReplicationLocation GetBucketReplicationProgress oss:GetBucketReplicationProgress Object级别 API Action GetObject oss:GetObject HeadObject oss:GetObject PutObject oss:PutObject PostObject oss:PutObject InitiateMultipartUpload oss:PutObject UploadPart oss:PutObject CompleteMultipart oss:PutObject DeleteObject oss:DeleteObject DeleteMultipartObjects oss:DeleteObject AbortMultipartUpload oss:AbortMultipartUpload ListParts oss:ListParts CopyObject oss:GetObject,oss:PutObject UploadPartCopy oss:GetObject,oss:PutObject AppendObject oss:PutObject GetObjectAcl oss:GetObjectAcl PutObjectAcl oss:PutObjectAcl Resource Resource指代的是OSS上面的某个具体的资源或者某些资源（支持*通配），resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name}，即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表，可以有多个Resource。其中的region字段暂时不做支持，设置为*。 Effect Effect代表本条的Statement的授权的结果，分为Allow和Deny，分别指代通过和禁止。多条Statement同时匹配成功时，禁止（Deny）的优先级更高。 例如，期望禁止用户对某一目录进行删除，但对于其他文件有全部权限： { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:bucketname" ] }, { "Effect": "Deny", "Action": [ "oss:DeleteObject" ], "Resource": [ "acs:oss:*:*:bucketname/index/*", ] } ] } Condition Condition代表Policy授权的一些条件，上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。 OSS支持的Condition如下： condition 功能 合法取值 acs:SourceIp 指定ip网段 普通的ip，支持*通配 acs:UserAgent 指定http useragent头 字符串 acs:CurrentTime 指定合法的访问时间 ISO8601格式 acs:SecureTransport 是否是https协议 “true”或者”false” oss:Prefix 用作ListObjects时的prefix 合法的object name 更多示例 针对具体场景更多的授权策略配置示例，可以参考教程示例：控制存储空间和文件夹的访问权限和OSS授权常见问题。 Policy在线图形化便捷配置工具，请单击这里。 最佳实践 RAM和STS使用指南

详细解答可以参考官方帮助文档 发送访问OSS的请求 您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下： 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner，也称为开发者。第三方用户是指访问Bucket里资源的用户。 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说，如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。 AccessKey 类型 目前访问 OSS 使用的 AK（AccessKey）有三种类型，具体如下： 阿里云账号AccessKey 阿里云账号AK特指Bucket拥有者的AK，每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对（AccessKeyId和AccessKeySecret）。 用户可以登录AccessKey管理控制台，申请新增或删除AK对。 每个AK对都有active/inactive两种状态。 Active 表明用户的 AK 处于激活状态，可以在身份验证的时候使用。 Inactive 表明用户的 AK 处于非激活状态，不能在身份验证的时候使用。 说明 请避免直接使用阿里云账户的 AccessKey。 RAM子账号AccessKey RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM，您可以集中管理您的用户（比如员工、系统或应用程序），以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的，并且这些账号下不能拥有实际的任何资源，所有资源都属于主账号。 STS账号AccessKey STS（Security Token Service）是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。 身份验证具体实现 目前主要有三种身份验证方式： AK验证 RAM验证 STS验证 当用户以个人身份向OSS发送请求时，其身份验证的实现如下： 用户将发送的请求按照OSS指定的格式生成签名字符串。 用户使用AccessKeySecret对签名字符串进行加密产生验证码。 OSS收到请求以后，通过AccessKeyId找到对应的AccessKeySecret，以同样的方法提取签名字符串和验证码。 如果计算出来的验证码和提供的一样即认为该请求是有效的。 否则，OSS将拒绝处理这次请求，并返回HTTP 403错误。 对于用户来说可以直接使用OSS提供的SDK，配合不同类型的AccessKey即可实现不同的身份验证。 权限控制 针对存放在Bucket的Object的访问，OSS提供了多种权限控制，主要有： Bucket级别权限 Object级别权限 账号级别权限（RAM） 临时账号权限（STS） Bucket级别权限 Bucket权限类型 OSS提供ACL（Access Control List）权限控制方法，OSS ACL提供Bucket级别的权限访问控制，Bucket目前有三种访问权限：public-read-write，public-read和private，它们的含义如下： 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 任何人（包括匿名访问）都可以对该Bucket中的Object进行读/写/删除操作；所有这些操作产生的费用由该Bucket的Owner承担，请慎用该权限。 public-read 公共读，私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作；任何人（包括匿名访问）可以对Object进行读操作。 private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作；其他人在未经授权的情况下无法访问该Bucket内的Object。 Bucket权限设定和读取方法 功能使用参考： API：Put BucketACL SDK：Java SDK-设置Bucket ACL 控制台：创建Bucket权限设置 API：Get BucketACL SDK：Java SDK-获取Bucket ACL Object级别权限 Object权限类型 OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限：private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置，这个操作只有Bucket Owner有权限执行。 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 该ACL表明某个Object是公共读写资源，即所有用户拥有对该Object的读写权限。 public-read 公共读，私有写 该ACL表明某个Object是公共读资源，即非Object Owner只有该Object的读权限，而Object Owner拥有该Object的读写权限。 private 私有读写 该ACL表明某个Object是私有资源，即只有该Object的Owner拥有该Object的读写权限，其他的用户没有权限操作该Object。 default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源，即Bucket是什么权限，Object就是什么权限。 说明 如果没有设置Object的权限，即Object的ACL为default，Object的权限和Bucket权限一致。 如果设置了Object的权限，Object的权限大于Bucket权限。举个例子，如果设置了Object的权限是public-read，无论Bucket是什么权限，该Object都可以被身份验证访问和匿名访问。 Object权限设定和读取方法 功能使用参考： API：Put Object ACL SDK：Java SDK-ObjectACL 中设定Object ACL API：Get Object ACL SDK：Java SDK-ObjectACL 中读取Object ACL 账号级别权限（RAM） 使用场景 如果您购买了云资源，您的组织里有多个用户需要使用这些云资源，这些用户只能共享使用您的云账号AccessKey。这里有两个问题： 您的密钥由多人共享，泄露的风险很高。 您无法控制特定用户能访问哪些资源（比如Bucket）的权限。 解决方法：在您的阿里云账号下面，通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号，创建出来的账号被称为子账号，使用子账号的AccessKey只能使用主账号授权的操作和资源。 具体实现 有关RAM详情，请参考RAM用户手册。 对于授权中需要的Policy的配置方式可以参考本章最后一节：RAM和STS授权策略（Policy）配置。 临时账号权限（STS） 使用场景 对于您本地身份系统所管理的用户，比如您的App的用户、您的企业本地账号、第三方App，也有直接访问OSS资源的可能，将这部分用户称为联盟用户。此外，用户还可以是您创建的能访问您的阿里云资源的应用程序。 对于这部分联盟用户，通过阿里云STS (Security Token Service) 服务为阿里云账号（或RAM用户）提供短期访问权限管理。您不需要透露云账号（或RAM用户）的长期密钥（如登录密码、AccessKey），只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题，访问凭证过期后会自动失效。 用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。 具体实现 STS安全令牌、角色管理和使用相关内容详情，请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可，也可以直接使用STS SDK来调用该方法。 RAM和STS应用场景实践 对于不同的应用场景，涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。 以一个移动App举例。假设您是一个移动App开发者，打算使用阿里云OSS服务来保存App的终端用户数据，并且要保证每个App用户之间的数据隔离，防止一个App用户获取到其它App用户的数据。 方式一：使用AppServer来做数据中转和数据隔离如上图所示，您需要开发一个AppServer。只有AppServer能访问云服务，ClientApp的每次读写数据都需要通过AppServer，AppServer来保证不同用户数据的隔离访问。 对于该种使用方式，使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号（主账号）的密钥访问OSS，避免出现安全问题。 方式二：使用STS让用户直接访问OSS STS方案描述如下图所示：方案的详细描述如下： App用户登录。App用户和云账号无关，它是App的终端用户，AppServer支持App用户登录。对于每个有效的App用户来说，需要AppServer能定义出每个App用户的最小访问权限。 AppServer请求STS服务获取一个安全令牌（SecurityToken）。在调用STS之前，AppServer需要确定App用户的最小访问权限（用Policy语法描述）以及授权的过期时间。然后通过扮演角色（AssumeRole）来获取一个代表角色身份的安全令牌。 STS返回给AppServer一个有效的访问凭证，包括一个安全令牌（SecurityToken）、临时访问密钥（AccessKeyId, AccessKeySecret）以及过期时间。 AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时，ClientApp需要向AppServer申请新的有效访问凭证。比如，访问凭证有效期为1小时，那么ClientApp可以每30分钟向AppServer请求更新访问凭证。 ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证，并会依赖STS服务来验证访问凭证，正确响应用户请求。 RAM和STS授权策略（Policy）配置 对于RAM或者STS授权中使用Policy，详细规则如下。 示例 先看下面的一个Policy示例： { "Version": "1", "Statement": [ { "Action": [ "oss:GetBucketAcl", "oss:ListObjects" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket" ], "Effect": "Allow", "Condition": { "StringEquals": { "acs:UserAgent": "java-sdk", "oss:Prefix": "foo" }, "IpAddress": { "acs:SourceIp": "192.168.0.1" } } }, { "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket/file*" ], "Effect": "Allow", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.0.1" } } } ] } 这是一个授权的Policy，用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement（一条Policy当中可以有多条Statement）。Statement里面规定了相应的Action、Resource、Effect和Condition。 这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户，并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk，源IP为192.168.0.1的时候鉴权才能通过，被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket（ListObjects）的时候起作用的，关于这个字段的解释详见OSS的API文档。 配置细则 Version Version定义了Policy的版本，本文档中sw2q的配置方式，设置为1。 Statement 通过Statement描述授权语义，其中可以根据业务场景包含多条语义，每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查，所有匹配成功的Statement会根据Effect的设置不同分为通过（Allow）、禁止（Deny），其中禁止（Deny）的优先。如果匹配成功的都为通过，该条请求即鉴权通过。如果匹配成功有一条禁止，或者没有任何条目匹配成功，该条请求被禁止访问。 Action Action分为三大类：Service级别操作，对应的是GetService操作，用来列出所有属于该用户的Bucket列表。 Bucket级别操作，对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作，操作的对象是Bucket，它们的名称和相应的接口名称一一对应。 Object级别操作，分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload，操作对象是Object。 如想授权某一类的Object的操作，可以选择这几种的一种或几种。另外，所有的Action前面都必须加上oss:，如上面例子所示。Action是一个列表，可以有多个Action。具体的Action和API接口的对应关系如下： Service级别 API Action GetService（ListBuckets） oss:ListBuckets Bucket级别 API Action PutBucket oss:PutBucket GetBucket（ListObjects） oss:ListObjects PutBucketAcl oss:PutBucketAcl DeleteBucket oss:DeleteBucket GetBucketLocation oss:GetBucketLocation GetBucketAcl oss:GetBucketAcl GetBucketLogging oss:GetBucketLogging PutBucketLogging oss:PutBucketLogging DeleteBucketLogging oss:DeleteBucketLogging GetBucketWebsite oss:GetBucketWebsite PutBucketWebsite oss:PutBucketWebsite DeleteBucketWebsite oss:DeleteBucketWebsite GetBucketReferer oss:GetBucketReferer PutBucketReferer oss:PutBucketReferer GetBucketLifecycle oss:GetBucketLifecycle PutBucketLifecycle oss:PutBucketLifecycle DeleteBucketLifecycle oss:DeleteBucketLifecycle ListMultipartUploads oss:ListMultipartUploads PutBucketCors oss:PutBucketCors GetBucketCors oss:GetBucketCors DeleteBucketCors oss:DeleteBucketCors PutBucketReplication oss:PutBucketReplication GetBucketReplication oss:GetBucketReplication DeleteBucketReplication oss:DeleteBucketReplication GetBucketReplicationLocation oss:GetBucketReplicationLocation GetBucketReplicationProgress oss:GetBucketReplicationProgress Object级别 API Action GetObject oss:GetObject HeadObject oss:GetObject PutObject oss:PutObject PostObject oss:PutObject InitiateMultipartUpload oss:PutObject UploadPart oss:PutObject CompleteMultipart oss:PutObject DeleteObject oss:DeleteObject DeleteMultipartObjects oss:DeleteObject AbortMultipartUpload oss:AbortMultipartUpload ListParts oss:ListParts CopyObject oss:GetObject,oss:PutObject UploadPartCopy oss:GetObject,oss:PutObject AppendObject oss:PutObject GetObjectAcl oss:GetObjectAcl PutObjectAcl oss:PutObjectAcl Resource Resource指代的是OSS上面的某个具体的资源或者某些资源（支持*通配），resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name}，即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表，可以有多个Resource。其中的region字段暂时不做支持，设置为*。 Effect Effect代表本条的Statement的授权的结果，分为Allow和Deny，分别指代通过和禁止。多条Statement同时匹配成功时，禁止（Deny）的优先级更高。 例如，期望禁止用户对某一目录进行删除，但对于其他文件有全部权限： { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:bucketname" ] }, { "Effect": "Deny", "Action": [ "oss:DeleteObject" ], "Resource": [ "acs:oss:*:*:bucketname/index/*", ] } ] } Condition Condition代表Policy授权的一些条件，上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。 OSS支持的Condition如下： condition 功能 合法取值 acs:SourceIp 指定ip网段 普通的ip，支持*通配 acs:UserAgent 指定http useragent头 字符串 acs:CurrentTime 指定合法的访问时间 ISO8601格式 acs:SecureTransport 是否是https协议 “true”或者”false” oss:Prefix 用作ListObjects时的prefix 合法的object name 更多示例 针对具体场景更多的授权策略配置示例，可以参考教程示例：控制存储空间和文件夹的访问权限和OSS授权常见问题。 Policy在线图形化便捷配置工具，请单击这里。 最佳实践 RAM和STS使用指南

回 2楼(优创科技) 的帖子 您好， 能否贴出您的 httpd-ssl.conf 的文件配置内容？ ------------------------- 回 4楼(优创科技) 的帖子 您好， 好象回帖的内容是空白，没有内容的喔。 ------------------------- 回 6楼(优创科技) 的帖子 您好， 请尝试将 <VirtualHost _default_:443> 这一行到  </VirtualHost> 的内容删除后，再试试。 ------------------------- 回 9楼(优创科技) 的帖子 您好， 感谢您的反馈，同时很高兴听到您已经解决了问题。 ------------------------- 回 12楼(jingyun) 的帖子 您好， 个人估计，也是可以的。请问您使用的wampserver版本是多少？ ------------------------- 回 14楼(jingyun) 的帖子 您好， 好哩，那我为您找个测试机来测试。 ------------------------- 回 17楼(jingyun) 的帖子 您好， 已经为您写好帖子了，《在 Windows 2008 R2 64位系统为 wampserver apache 不同网站配置不同SSL证书（SNI）》 - https://bbs.aliyun.com/read/305369.html 一般来说，文件的路径建议添加英文引号。如果您的配置有误，一般apache是启动失败的哩。 在上一楼层的phpstudy配置文件内容中，个人觉得应该是不完整的，如虚拟站点的路径等关键信息，没有。 ------------------------- 回 19楼(jingyun) 的帖子 您好， 如您截图中的两个站点均少了如下两个配置项：绑定的域名（ServerName）和站点的文件路径（DocumentRoot）。         ServerName      "portal.anqun.org"         DocumentRoot    "C:\www\portal.anqun.org" ------------------------- 回 21楼(jingyun) 的帖子 您好， 如果phpstudy没有使用443的端口，那么可能您需要检查一下apache的配置文件中，有没有配置使用443端口了喔， 如： Listen 443 ------------------------- 回 23楼(jackyli888888) 的帖子 您好， 欢迎来到阿里云论坛。 请问您指的是apache的80还是443端口从外网连接失败呢？ ------------------------- 回 25楼(云淡风轻poe) 的帖子 您好， 抱歉给您带来不便。 能否查看一下apache的错误日志呢？ ------------------------- 回 27楼(云淡风轻poe) 的帖子 您好， 无论是 http 还是https ，站点  airpal.012316.cn 的文件根目录都是 E:\www\airpal 吗？ ------------------------- 回 30楼(云淡风轻poe) 的帖子 您好， 如云盾提供的免费证书，一般是单域名的， 如果您想为 airpal.012316.cn 布置https访问，那么在云盾申请证书时，应该是提交 airpal.012316.cn 的域名，而不是 012316.cn 的喔。 如果您的网站程序不是很特别的，是可以仅为 airpal.012316.cn 启用https访问，其它站点使用http。 ------------------------- 回 31楼(云淡风轻poe) 的帖子 您好， 一般与phpstudy的版本关系不大，因为即使是2014年版本，apache应该也支持https的配置。 ------------------------- 回 34楼(亘平网络) 的帖子 您好， 欢迎来到阿里云论坛。 一般来说，申请证书时填写的域名是与站点的访问地址要一模一样的，即如果您想为 website.genping.net 启用 https 访问，那么申请证书时，应该填写 website.genping.net，而不是 genping.net 喔。 ------------------------- 回 36楼(wilson何朝威) 的帖子 您好， 抱歉延时回复。 请问，apache的日志里有相关的错误信息提示吗？ ------------------------- 回 39楼(云淡风轻poe) 的帖子 您好， 截图中，是提示证书不符。默认Windows服务器会为自己签发一个证书（如第二个框里显示的计算机名证书）。 ------------------------- 回 40楼(云淡风轻poe) 的帖子 您好， 是哩，很可能是您的SVN程序先占用了TCP 443的端口，所以导致apache不能再次绑定到443端口了。 ------------------------- 回 43楼(ccj803) 的帖子 您好， 抱歉给您带来不便。 如果您尝试后失败，那我有空时，为您再次按帖子里的步骤重复操作一次，看是否有遗漏了。 ------------------------- 回 45楼(ccj803) 的帖子 您好， 下载的四个文件中，不一定需要全部用上的喔。 ------------------------- 回 43楼(ccj803) 的帖子 您好， 刚才我照着例子，大概重新操作了一次，好象也能成功访问https站点喔。 您配置成功了吗？ ------------------------- 回 50楼(起床失败) 的帖子 您好， 现在查看您的https站点，访问正常喔。 是已经配置成功了吗？ --2017-04-08 09:21:20--   https://cs.xncsbw.cn/ Resolving cs.xncsbw.cn (cs.xncsbw.cn)... 60.205.171.126 Connecting to cs.xncsbw.cn (cs.xncsbw.cn)|60.205.171.126|:443... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://cs.xncsbw.cn/member/ [following] --2017-04-08 09:21:20--   http://cs.xncsbw.cn/member/ Connecting to cs.xncsbw.cn (cs.xncsbw.cn)|60.205.171.126|:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: /member/login.php [following] --2017-04-08 09:21:20--   http://cs.xncsbw.cn/member/login.php Reusing existing connection to cs.xncsbw.cn:80. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘index.html.14’ ------------------------- 回 52楼(好恶心啊) 的帖子 您好， 欢迎来到阿里云论坛。 感谢您的积极反馈喔，很高兴这个帖子的内容能帮到您。 ------------------------- 回 55楼(haonan) 的帖子 您好， 欢迎来到阿里云论坛。 当启用 httpd-ssl.conf 后，apache启动失败，日志中是否有提示有用的信息呢？ ------------------------- 回 57楼(baidapi) 的帖子 您好， 欢迎来到阿里云论坛。 请问apache无法启动，日志里有没有显示相应的原因呢？ ------------------------- 回 59楼(ezhixingli) 的帖子 您好， 抱歉延时回复。 请问 apache 日志内容中，有相关的错误信息吗？ ------------------------- 回 64楼(昵称就不留) 的帖子 您好， 可以尝试在命令提示符程序里运行httpd.exe，看一下是否有不同的信息提示喔。 ------------------------- 回 63楼(茂名微时代) 的帖子 您好， 欢迎来到阿里云论坛。 请问您的站点访问网址是什么呢？ ------------------------- 回 68楼(昵称就不留) 的帖子 您好， 可能复制内容到 httpd-ssl.conf  时，有特殊字符，导致出错。 您可以尝试用其它程序来打开检查，如notepad2。 ------------------------- 回 70楼(昵称就不留) 的帖子 您好， 或许您配置SSL的内容有误呢， --2017-07-02 16:59:05--   https://www.tdshicai.com/ Resolving www.tdshicai.com (www.tdshicai.com)... 162.159.211.85, 162.159.210.85 Connecting to www.tdshicai.com (www.tdshicai.com)|162.159.211.85|:443... connected. GnuTLS: A TLS fatal alert has been received. GnuTLS: received alert [40]: Handshake failed Unable to establish SSL connection. ------------------------- 回 72楼(昵称就不留) 的帖子 您好， 加油。今天如果还没成功，在暂停后，明天再试试喔。 ------------------------- 回 73楼(茂名微时代) 的帖子 您好， 从这里的检测结果来看，提示是当前服务器的配置不支持TLS1.2: https://www.ssllabs.com/ssltest/analyze.html?d=xcx.maomingweishidai.net 或许您可以使用      SSLCipherSuite DEFAULT 来替换试试。 ------------------------- 回 76楼(茂名微时代) 的帖子 您好， 就是可以尝试将例子中的： SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP 替换成： SSLCipherSuite DEFAULT 来试试。现在我没有测试机，所以暂时不能为您测试喔。 ------------------------- 回 78楼(albertdsg) 的帖子 您好， 欢迎来到阿里云论坛。 apache不能启动成功，在日志文件中，有详细的错误信息吗？ ------------------------- 回 81楼(boss_2016) 的帖子 您好， 欢迎来到阿里论坛。 从您提供的日志内容来看，可能关键是这个： Session Cache is not configured 请再尝试检查一下apache的配置文件哩。 ------------------------- 回 83楼(大树先生van) 的帖子 您好， 欢迎来到阿里云论坛。 很高兴听到这个帖子的内容对您有帮助。 ------------------------- 回 85楼(呵呵啦啦) 的帖子 您好， 抱歉给您带来不便。 或许您可以尝试看看apache的错误日志，看里边有没有关键的信息提示哩。 83楼的网友还提到一个细节，或许您也可以参考一下。 ------------------------- 回 88楼(aaaaa11123) 的帖子 您好， 看上边的配置内容， 好象您的https 443虚拟站点配置是被注释掉（有#）的喔。 ------------------------- 回 90楼(aaaaa11123) 的帖子 您好， 您可以通过以下方向来诊断， a. 先检查当前系统是否有使用 443 端口 b. 检查apache的日志，看是否有相应的错误信息提示 ------------------------- 回 93楼(aaaaa11123) 的帖子 您好， 能否运行 netstat -noa | find ":443" ，看看输出结果？ ------------------------- 回 99楼(aaaaa11123) 的帖子 您好， 您有进程在使用443的端口，且apache日志里没有相关的错误信息。 能否贴出您的ssl站点配置内容呢？ 如之前的，带#的就是吗？ ------------------------- 回 102楼(aaaaa11123) 的帖子 您好， 请尝试将ssl的站点放在 httpd-ssl.conf 里配置， 对照着里边的例子来写，如要指明证书文件的路径等。 ------------------------- 回 104楼(aaaaa11123) 的帖子 您好， 如此修改 httpd-ssl.conf 后，重启apache后， https站点能访问了吗？ ------------------------- 回 108楼(aaaaa11123) 的帖子 您好， 在浏览器里访问 https://您的域名 ， 会有什么样的结果呢？ ------------------------- 回 111楼(aaaaa11123) 的帖子 您好， 那离成功仅有一小步了。 请检查ECS实例的安全组规则， 看规则是否允许访问tcp 443端口喔。 ------------------------- 回 113楼(aaaaa11123) 的帖子 您好， 请截图看看您的ECS实例安全组规则。 可以在“高级模式”里点“附件”的按钮来上传截图文件哩。 ------------------------- 回 115楼(aaaaa11123) 的帖子 您好， 看图中的规则，好象全部放行了呀。 您的系统有没有启用防火墙之类的呢？ ------------------------- 回 118楼(aaaaa11123) 的帖子 您好， 那您之前可以在本地访问https站点，用的是什么网址访问的呢？ ------------------------- 回 120楼(aaaaa11123) 的帖子 您好， 可在本地用如 portqueryui.exe 的工具来测试远程服务器的443端口是否可以访问， 如这样的结果： TCP port 443 (https service): FILTERED portqry.exe -n www.shanxiwap.cn -e 443 -p TCP exits with return code 0x00000002 TCP port 443 (https service): LISTENING portqry.exe -n www.aliyun.com -e 443 -p TCP exits with return code 0x00000000. ------------------------- 回 120楼(aaaaa11123) 的帖子 您好， portqueryui.exe 的工具可以从微软网站上下载得到， https://www.microsoft.com/en-us/download/details.aspx?id=24009 当然，也可以用其它工具来测试，如 telnet 等。 请多测试，多尝试，多对比。 ------------------------- 回 123楼(感觉2017) 的帖子 您好， 为您写了下边这个帖子，希望对您有用： 《为 “护卫神 apache大师”站点添加ssl证书，实现https访问》 - https://bbs.aliyun.com/read/541609.html ------------------------- 回 126楼(无限空间2) 的帖子 版主回复： 如果可以，请查看apache的日志文件，看看里边是否有具体的启动失败原因。 ------------------------- 回 128楼(林吊吊) 的帖子 版主回复： 您可以逐行检查一下 httpd-ssl.conf 的内容， 如确认 SSLSessionCache 这一行的配置是否有效。 ------------------------- 回 130楼(wylove) 的帖子 版主回复： 可以如同复用80端口那样复用443端口的喔， 您为443端口设置vhost了吗？ ------------------------- 回 132楼(wylove) 的帖子 版主回复： 能否查看一下apache的错误日志文件，看具体是什么导致apache启动失败？ 如会否是因为第二个站点的证书路径错误之类的。 ------------------------- 回 134楼(zjzl85) 的帖子 版主回复： 您的意思是，您的一个阿里云ECS云服务器有两个网站，一个A网站，一个B网站？ A网站配置https访问后，apache启动失败吗？ ------------------------- 回 136楼(zjzl85) 的帖子 版主回复： 一般https是跟着域名走的，如果您的证书是发给 zll.1680898.cn 的，那只能是以 https://zll.1680898.cn 的网址来访问喔。 如果B服务器在添加ssl配置后启动失败，建议检查一下apache的错误日志，看看是什么原因导致的。 ------------------------- 回 138楼(zjzl85) 的帖子 版主回复： 那在 cmd.exe 里，转到 httpd.exe 所在的目录，运行一下 httpd.exe ，看看会有哪些信息输出。 ------------------------- 回 140楼(zjzl85) 的帖子 版主回复： httpd.exe 是提示您，在配置文件 httpd-ssl.conf 中 <VirtualHost> 与  </VirtualHost> 不匹配。 您可以数一下，<VirtualHost> 出现的次数是2次，而 </VirtualHost> 出现的次数是3次，一般它们是俩兄弟，成对出现的。 ------------------------- 回 143楼(zjzl85) 的帖子 版主回复： 好象您的配置文件中，引用了ipv6的地址，和多次listen了443端口。 或，您先后重复运行了httpd.exe。 请再细心对照着出错信息，检查一下。 ------------------------- 回 146楼(起风的森林) 的帖子 版主回复： 抱歉现在才看到您的信息， 如果apache能成功启动，本地里也能查到443端口的使用状态， 或许您需要检查一下实例的安全组规则，看是否有允许外网访问443端口： https://help.aliyun.com/document_detail/25471.html ------------------------- 回 152楼(起风的森林) 的帖子 版主回复： 有啊，如我头像上边写着的（旺旺：nectar2）。 ------------------------- 回 158楼(cvwif) 的帖子 您好， 可通过如.htaccess文件来设置http自动跳转到https。 ------------------------- 回 160楼(cvwif) 的帖子 您好， 那现在您的站点，能从http自动跳到https了吗？ ------------------------- 回 162楼(cvwif) 的帖子 您好， 可以参考一下这里的讨论： https://stackoverflow.com/questions/10489895/http-to-https-through-htaccess 是不是http到https的设置或规则有冲突，所以没达到预期的效果？ ------------------------- 回 164楼(cvwif) 的帖子 您好， 很高兴您能更新回复。 欢迎有空时，多来论坛逛逛喔。 ------------------------- 回 166楼(开心农场) 的帖子 您好， 如果443端口使用正常，但内容为空，或许需要检查一下https站点的设置，如文件路径等。

《操作系统》课程设计报告课程设计题目：操作系统课程设计 设计时间：2016/1/10一、 课程设计目的与要求需要完成的内容：（1） 安装虚拟机：Vmware、Vmware palyer (free)（推荐）、Virtualbox（推荐）、VMLite、Xen、Virtuozzo、KVM（2） 安装和使用Linux（推荐SUSE）（注意包含内核源码和内核开发工具等）（3） Linux内核源代码配置和重编（4） 找到VFS和一个具体文件系统的源代码（ext3或ext4）（5） 读懂VFS和具体文件系统如何关联（如何体现virtual file switch）（6） 找到具体文件系统的read或write函数，使用printk（使用方法和printf一样）向后台打印文件读写信息。（read或write函数选一个即可）（7） 使用dmesg –c查看后台的输出。可以附加的功能（8） 复制ext3或ext4的源代码（注意与当前使用的文件系统有区别），修改Makefile文件，使用模块编译方式（9） 修改ext3或ext4的源代码，实现新的文件系统。（至少需要修改文件系统的名称，最好能对文件写操作向系统后台打印出信息。）（10） 动态加载和卸载新的文件系统。二、 课程设计内容（1） 安装虚拟机（2） 安装和使用Linux（3） Linux内核源代码配置和重编（4） 提取并动态加载和卸载新的文件系统三、 课程设计设备与环境设备信息：PC 虚拟机：VM11 四、 设计正文（包括分析与设计思路、各模块流程图、带注释的主要算法源码、内核编译过程以及动态模块加载过程等，如有改进或者拓展，请重点用一小节进行说明）（1） 安装虚拟机（2） 安装和使用Linux（推荐SUSE）（注意包含内核源码和内核开发工具等）安装OpenSUSE，并下载相近版本的内核源码 初始内核版本 下载的源代码包 （3） Linux内核源代码配置和重编利用vmtools（虚拟机提供的可以在宿主机和虚拟机之间自由复制文件的工具）将内核源码包复制进虚拟机，解压到/home/a123/linux-3.12.51 *因为分配的磁盘空间比较小，所以没有按照惯例把内核源码放在/usr/src目录下（如果放在这里，会出现空间不足的情况）附：磁盘分配情况/swap（交换分区） 2.4G/（根目录） 11G/home（用户目录） 13G 解压好的内核源码文件在编译前需要稍作修改（6），并且缺乏一个config文件告诉编译器编译哪些功能。Config文件可以用make menuconfig命令生成，但是需要自己选择相应的功能，太过复杂，这里有一个简便的方法因为下载的内核源码是相近的版本，所以可以使用现有版本的config文件，该文件在/boot目录下使用cp /boot/config-3.11.6-4-desktop .config命令将此文件复制过来 注意：应当在内核所在的文件目录下使用此命令复制成功 执行 make menuconfig命令，进入选择界面，直接保存退出即可虽然新版本的Linux可以直接执行make一步完成所有的编译工作，但此次课程设计仍然采用以前的编译的方式 执行 make bzImage命令——编译压缩的内核编译完成 执行 make modules命令——编译模块 执行 make modules_install命令——安装模块 注： 在make menuconfig时我在General setup中把版本号改过 执行 make install命令——安装新内核 Reboot重启 说明内核修改安装完毕，成功（4） 找到VFS和一个具体文件系统的源代码（ext3或ext4）VFS：虚拟文件系统，顾名思义。它为应用程序员提供一层抽象，屏蔽底层各种文件系统的差异。Linux的文件系统采用面向对象的方式设计，这使得Linux的文件系统非常容易扩展，我们可以非常容易将一个新的文件系统添加到Linux中。在此主要对象之一super_block位于中 代码量巨大，此为部分代码Ext4在fs文件夹下的ext4文件夹内 此处打开file.c用vim打开file.c部分代码如下 （5） 读懂VFS和具体文件系统如何关联（如何体现virtual file switch）在（4）中已经提到，VFS是C语言写的一个面向对象的设计，比如我们要调用alloc_inode方法：sb->s_op->alloc_inode(sb)。这里与面向对象语言的差别是，面向对象语言里实例方法可以访问到this，这样就可以访问到自身的所有成员，但是在C里却做不到，所以需要将自身作为参数传入到函数中、图一表示了对文件写操作的调用过程 （6） 找到具体文件系统的read或write函数，使用printk（使用方法和printf一样）向后台打印文件读写信息。（read或write函数选一个即可）因为Linux系统对文件的操作是通过函数调用来实现的，所以在此我修改的是vfs这一层，找到fs，目录下的read_write.c并打开找到do_sync_read函数，在其返回前加入printk语句 （7） 使用dmesg –c查看后台的输出。 （8） 复制ext3或ext4的源代码（注意与当前使用的文件系统有区别），修改Makefile文件，使用模块编译方式 （9） 修改ext3或ext4的源代码，实现新的文件系统。（至少需要修改文件系统的名称，最好能对文件写操作向系统后台打印出信息。） 使其在加载和卸载的时候能够printk到buffer缓冲中（10） 动态加载和卸载新的文件系统。使用insmod语句加载使用lsmod语句加载 加载成功接下来使用dmesg 查看缓冲区内容 成功接下来使用rmmod语句卸载模块 成功五、 课程设计结果及分析课程设计结果：成功分析：Linux文件系统使用了面向对象的设计方法，保证了其对用户的透明，VFS层实现了系统与文件系统的无关性，增加了系统对不同文件系统的兼容性。六、 总结与进一步改进设想总结：1.编译内核的时候，可以使用make XXX –j8这样可以开启多线程编译（我的虚拟机分配的是8核心），加快编译速度2.printk语句我写的是printk（”””DoingRead”）;本意是利用printk的优先级，将其输出到用户态的控制台，结果语法错误，并没有输出到控制台改进设想：修改的文件前加上语句，实现对控制台的输出 define KERN_EMERG 0（因为缺少这个宏，导致系统并没有理解我的0是什么意思） 七、 答辩（或汇报）记录（包括问题和答案，每个人不少于3个） 显示内核版本 使用dmesg –c命令 加载新模块 八、 参考文献 鸟哥的Linux私房菜 百度百科：printk概述http://baike.baidu.com/link?url=Kv5e2xb9thGENkIvSQmjpkYb8kbKoNvEhmt2oICTmDAn0wj2YADVf8dsrzBtz2fRt0uwa_3joQ-o40wKwwL68a Linux虚拟文件系统(VFS)http://www.cnblogs.com/yuyijq/archive/2013/02/24/2923855.html LinuxEXT4文件系统分析http://wenku.baidu.com/link?url=Wi-vyrROUIJqRk4eSsuwOwRe0Sf-ydXamWNR0H2HCrN9CPHJg80lXpu0Gi_ZGT-X5yKnknl86ooHdckHhJxybmyBR2szWsPDOV0IPJ6fJXO

在浏览器里输入 [url=file://\\10.2.6.120]\\10.2.6.120[/url] 弹出以下“\\10.2.6.120无法访问。你可能没有权限访问网络资源。请与这台服务器的管理员联系以查明你是否有访问权限。拒绝访问。” 现在公司最喜欢用WIN2000/ xp，但是这个系统本身就带有些系统排斥，因为内网的资源是共享的，所以经常碰到等入不了的问题，系统提示：此工作组的服务器列表无法使用。下面就着手解决.但是首先,我们先来看下网络邻居互相访问的最基本的条件: 1.双方计算机打开，且设置了网络共享资源； 2.双方的计算机添加了 "Microsoft 网络文件和打印共享" 服务； 3.双方都正确设置了网内IP地址，且必须在一个网段中； 4.双方的计算机中都关闭了防火墙，或者防火墙策略中没有阻止网上邻居访问的策略。 5. XP首次使用时在网上邻居的属性里面已经新建一个网络连接进行网络安装向导 6.计算机之间的物理连接正常。在桌面计算机中，每个网卡后面的指示灯是亮的，集线器或交换机是打开的，而且每个客户端连接的指示灯都是亮的，网线的水晶头接触良好。 7.确保所有计算机上都安装了TCP/IP，并且工作正常。 在Windows XP中默认安装了TCP/IP。但是，如果出了网络问题想卸载后重新安装TCP/IP就不容易了：在“本地连接”属性中显示的此连接使用下列项目列表中单击Internet协议(TCP/IP)项，您将发现卸载按钮不可用(被禁用)。 这是因为传输控制协议/Internet协议(TCP/IP)堆栈是Microsoft XP/ 2003的核心组件，不能删除。在这种情况下，如果需要重新安装TCP/IP以使TCP/IP堆栈恢复为原始状态。可以使用NetShell实用程序重置 TCP/IP堆栈，使其恢复到初次安装操作系统时的状态。方法是：在命令提示符后键入以下命令，然后按ENTER键：netsh int ip reset c:\resetlog.txt，其中，Resetlog.txt记录命令结果的日志文件，一定要指定，这里指定了Resetlog.txt日志文件及完整路径。运行此命令的结果与删除并重新安装TCP/IP协议的效果相同。 既然我们现在了解明白了这些条件,就可以着手解决: 第一种可能性就是本身系统系统浏览的正常现象。如微软公司文档中提到的预期的升级行为.详细的可以到这里看: http://support.microsoft.com/kb/304040/ZH-CN/ 还有一点, 在实际的网络运用中，安装Windows XP系统的电脑有时会出现不能与Windows 98、Windows 2000的电脑互相访问的问题，即使是开启Guest账号、安装NetBEUI协议、设置共享文件夹，也不能正常访问,这就属于系统本身浏览的政策现象. 第二种是开了防火墙，在XP中自带的防火墙会导致无法访问网络邻居.可以通过命令net view \\computername 来查看.不论是2000还是XP只要关掉防火墙就可以.同时确保防火墙没有禁止以下端口的通讯：UDP－137、UDP－138、TCP－139、 TCP－445（仅WIN2K及以后的操作系统）。 Windows XP最新的SP2补丁对ICS做了很大的改进，功能更强大了，ICS有了自己的设置项，安装SP2后，默认情况下，启用ICS防火墙，不允许任何外部主动连接，即使是本地的应用程序要访问网络也需要在许可列表中做设置。 但是防火墙阻断正常的网络浏览服务通讯，结果是别人在网上邻居中看不到你的计算机.这时候如果开启了ICS，打开属性，在服务这栏，选择添加，添加服务的对话框共有四个编辑框，最上边是描述服务名称，以便于记忆，从上到下第二个是应用服务的IP地址或名称，输入127.0.0.1表示本机。 下面连个是内外端口号，旁边的tcp/udp标示这个端口是udp连接还是tcp连接。 按照下面的表格输入3个服务 名称 协议 端口 NetBIOS Name Service UDP 137 NetBIOS Datagram Service UDP 138 NetBIOS Session Service TCP 139 PS: 137/UDP -- NetBIOS名称服务器,网络基本输入/输出系统(NetBIOS)名称服务器(NBNS)协议是TCP/IP上的NetBIOS (NetBT)协议族的一部分，它在基于NetBIOS名称访问的网络上提供主机名和地址映射方法。138/UDP -- NetBIOS数据报,NetBIOS数据报是TCP/IP上的NetBIOS (NetBT)协议族的一部分，它用于网络登录和浏览。 139/TCP -- NetBIOS会话服务,NetBIOS会话服务是TCP/IP上的NetBIOS (NetBT)协议族的一部分，它用于服务器消息块(SMB)、文件共享和打印。 第三种是查看Guest用户激活了没有，可以从“控制面板|管理工具|计算机管理|本地用户和组|用户”中找到“Guest”账户，并用鼠标右击打开 “Guest属性”对话框，去除这里的“账户已停用”复选框上的对钩标记 .Windows XP的Guest帐户允许其他人使用你的电脑，但不允许他们访问特定的文件，也不允许他们安装软件。对Windows XP Home Edition计算机或工作组中的Windows XP Professional计算机的所有网络访问都使用来宾帐户。使用net user guest确保为网络访问设置了来宾帐户，如果该帐户是活动的，命令输出中会出现一行类似下面这样的内容：Account active Yes；如果该帐户不是活动的，请使用下面的命令授予来宾帐户网络访问： net user guest /active:yes 或者打开控制面板－>用户帐户或者在管理工具－>计算机管理－>本地用户和组中打开Guest帐户.同时设置为允许Guest(来宾)帐号从网络上访问。 在运行里输入gpedit.msc，弹出组策略管理器，在‘计算机配置-Windows设置-本地策略-用户权利指派’中，有“拒绝从网络访问这台计算机”策略阻止从网络访问这台计算机，如果其中有GUEST帐号,解决办法是删除拒绝访问中的GUEST帐号。 第四种查看协议，IPX，netbeui，TIP/IP协议，选择开启，共享用的是139，445端口. Win2k安装NetBEUI协议. 网上邻居－>属性－>本地连接－>属性---->安装------>协议------->NetBEUI Protocol XP右击网上邻居-属性，选择要共享的网卡。把IP设置在局域网的同一个网段上。在XP中打开 TCP/IP 上的 NetBIOS 开始---->控制面板---->网络和 Internet 连接---->网络连接---->本地连接---->属性---->Internet 协议 (TCP/IP) ---->常规---->高级---->WINS选项---->NetBIOS---->启用 TCP/IP 上的 NetBIOS---->确定[点击2次] 第五种在共享文件夹前加个符号，比如￥，%等 第六种检查Win2000是否存在安全策略限制 开始 -> 运行 -> gpedit.msc -> 计算机配置 -> windows设置 -> 本地策略 -> 用户权利分配 -> 删除"拒绝从网络访问这台计算机"中的guest用户。 XP的主策略安全设置 开 始 -> 运行 -> gpedit.msc -> 计算机配置 -> windows设置 -> 安全设置 ->本地策略 ->用户权利分配 -> 从网络上访问此计算机"属性那里性质Everone或者在"拒绝从网络访问这计算机"属性中删除GUEST 第七种“文件及打印机共享”的限制，允许其他用户访问我的文件点击激活就可以，其他的一些比较少碰到的问题如内部IP地址发生了冲突，甚至包括Hub故障、线路故障等就不说了 第八种启动"计算机浏览器"服务.根据微软的文档工作组中的一台或多台计算机没有启动或已关闭（禁用）"计算机浏览器"服务也会导致访问网络邻居失败.打开就可以了 开始---->我的电脑---->管理---->服务和应用程序---->服务---->在右边的详细信息窗格中，检查"计算机浏览器"服务是否已启动，右击计算机浏览器，然后单击启动 第九种运行网络标识向导. 我的电脑---->属性---->计算机名选项卡----> 网络 ID按钮，开始“网络标识向导”： ---->下一步---->本机是商业网络的一部分，用它连接到其他工作着的计算机---->下一步---->公司使用没有域的网络---->下一步---->输入你的局域网的工作组名---->下一步---->完成 第十种检查RPC、Plug and Play服务已启动，检查相应的系统文件夹的权限，重新注册以下的动态链接库： regsvr32 netshell.dll regsvr32 netcfgx.dll regsvr32 netman.dll 第十一种设置帐号和密码. 由于WinNT内核的操作系统，在访问远程计算机的时候，好像总是首先尝试用本地的当前用户名和密码来尝试，可能造成无法访问，在这里把用户密码添加进去就可以了。 第十二种ping ip ,然后在地址输入栏中输入“192.168.1.8”，单击“确定”。 用搜索计算机的方法访问，计算机更新列表需要时间，搜索计算机可以加快更新列表。点击“网上邻居”右键中的“搜索计算机”，输入计算机名，点击“立即搜索”，就可以看到你要访问的计算机。直接双击右边计算机名就可以打开它了。 用映射驱动器的方法访问，进入DOS方式，输入“NET VIEW \killer”，回车这是查看计算机上有哪些共享文件夹，如D。再输入NET USE Z:\Killer\D将计算机IBM-ZB共享的文件夹D映射为H：盘，在命令提示符下键入“Z:”。你会发现你已经连到目标计算机上了。 如果一个文件共享的时候在文件名前上了符号如￥%隐藏文件，可以在DOS下net share可以看的到。 由于WIN是中断式操作系统，如果对OS不是很熟悉的话会产生误解，相关的网络浏览过程方面的资料. 十三.打开控制面板，在用户一项里打开GUEST用户，再在控制面板，管理工具里，打开计算机管理，在里面选择本地用户和组，再选择用户，在GUEST上点右键，选择属性，这里有两种选择方法一种是需要密码，一种是不需要密码，如果需要密码就把《用户不能更改密码》和《密码永不过期》打上勾，如果不需要密码就直接把上面所有的勾去掉！还有如果需要密码的话，记得在GUEST上点右键，选择所有任务，设置密码！这里就是设置访问权限了，这一切都完毕以后关闭计算机管理，然后再在管理工具里打开本地安全策略，在本地策略里选择《用户权利指派》在用户权利指派里找到《拒绝本地登陆》一项，并把它打开，把里面的 GUEST删除掉，然后再找到《拒绝从网络访问这台计算机》打开，也是同样把GUEST删除掉，再找到《从网络访问此计算机》打开，在里面添加GUEST 项，一切就OK了！如果是在WIN98下访问XP，需要在WIN98的网上邻居属性里添加一个NETBOIS协议！ 这样大家就可以在同一个子网里互访了！ 十四、解除windows xp的文件共享限制 在安装了windows xp的计算机上，即使网络连接和共享设置正确，使用其他系统的用户仍然无法访问该计算机。默认情况下，windows xp的本地安全设置要求进行网络访问的用户全部采用来宾方式。同时，在windows xp安全策略的用户权利指派中又禁止guest用户通过网络访问系统。这样两条相互矛盾的安全策略导致了网内其他用户无法通过网络访问使用windows xp的计算机。你可采用以下方法解决。 方法一、解除对guest账号的限制 点击“开始→运行”，在“运行”对话框中输入“gpedit.msc”，打开组策略编辑器，依次选择“计算机配置→windows设置→安全设置→本地策略→用户权利指派”，双击“拒绝从网络访问这台计算机”策略，删除里面的“guest”账号。这样其他用户就能够通过guest账号通过网络访问使用 windows xp系统的计算机了。 方法二、更改网络访问模式 打开组策略编辑器，依次选择“计算机配置→windows设置→安全设置→本地策略→安全选项”，双击“网络访问：本地账号的共享和安全模式”策略，将默认设置“仅来宾—本地用户以来宾身份验证”，更改为“经典：本地用户以自己的身份验证”。 现在，当其他用户通过网络访问使用windows xp的计算机时，就可以用自己的“身份”进行登录了。当该策略改变后，文件的共享方式也有所变化，在启用“经典：本地用户以自己的身份验证”方式后，我们可以对同时访问共享文件的用户数量进行限制，并能针对不同用户设置不同的访问权限。 不过我们可能还会遇到另外一个问题，当用户的口令为空时，访问还是会被拒绝。原来在“安全选项”中有一个“账户：使用空白密码的本地账户只允许进行控制台登录”策略默认是启用的，根据windows?xp安全策略中拒绝优先的原则，密码为空的用户通过网络访问windows xp的计算机时便会被禁止。我们只要将这个策略停用即可解决问题。 答案来源网络，供参考，希望对您有帮助

详细解答可以参考官方帮助文档 Q: ossfs适合什么样的程序？ ossfs能把oss bucket挂载到本地，如果您使用的软件没有支持OSS，但您又想让数据能自动同步到OSS，那么ossfs是很好的选择。 Q: ossfs有什么局限性？ 由于数据需要经过网络同步到云端，ossfs在性能和功能上可能与本地文件系统有差距。如果您想让数据库等对io要求很高的应用跑在ossfs挂载的盘上，请慎重考虑。和本地文件系统具体差异： 随机或者追加写文件会导致整个文件的重写。 元数据操作，例如list directory，性能较差，因为需要远程访问OSS服务器。 文件/文件夹的rename操作不是原子的。 多个客户端挂载同一个oss bucket时，依赖用户自行协调各个客户端的行为。例如避免多个客户端写同一个文件等等。 不支持hard link。 Q: ossfs一定要阿里云的机器才能用么？ ossfs不限制一定要阿里云的内网才可以使用，外网机器依然可以使用。 Q: ossfs能不能同时挂载多个OSS bucket？ 可以的，在passwd-ossfs文件中写入多个OSS配置信息即可。支持不同帐号的OSS。 Q: 我在yum/apt-get安装ossfs，遇到conflicts with file from package fuse-devel的错误，请问是怎么回事？ 您的系统中存在老版本的fuse，请先使用相关的包管理器卸载，再重新安装ossfs。 Q: ossfs工作不正常，如何debug？ 您可以使用在挂载时，加上-d -o f2参数，ossfs会把日志写入到系统日志中。在centos系统中，在/var/log/messages中。 您也可以在挂载时使用-f -d -o f2参数，ossfs会把日志输出到屏幕上。 Q: 为什么我在mount时遇到 ossfs: unable to access MOUNTPOINT /tmp/ossfs: Transport endpoint is not connected这样的错误？ 请先umount对应的目录。 请检查您在使用ossfs挂载时，填入的url参数是否正确，是否和bucket/access key id/access key secret匹配。 特别注意：url中不包含bucket的名字。例如：您在oss控制台中看到bucket的域名是这样的：ossfs-test-1.oss-cn-hangzhou.aliyuncs.com。那么填入的url则是：http://oss-cn-hangzhou.aliyuncs.com。 Q: ossfs提示ossfs: unable to access MOUNTPOINT /tmp/odat: No such file or directory 这是您未创建该目录导致的，在挂载前需要创建对应目录。 Q: 我把bucket挂载到本地后，ls目录，却收到operation not permitted错误，这是为什么？ 请检查您的bucket中，是否包含目录名含有不可见字符的OSS object。文件系统对文件/目录名有更严格的限制，因此会收到上述错误。使用其他工具对这些object重命名后，ls就能正确显示目录内容了。 Q: 我的一个目录下有非常多的文件，为什么ls该目录很慢？ 假设一个目录下有n个文件，那么ls该目录至少需要n次OSS http requests。在文件非常多的时候，这可能造成严重的性能问题。 您可以采用下面两个办法优化： 通过-omax_stat_cache_size=xxx参数增大stat cache的size，这样第一次ls会较慢，但是后续的ls就快了，因为文件的元数据都在本地cache中。默认这个值是1000，大约消耗4MB内存，请根据您机器内存大小调整为合适的值。 使用ls -f命令，这个命令会消除与OSS的n次http请求。 具体参见issue 13。 Q: ossfs挂载时如何设置权限？ 如果要允许其他用户访问挂载文件夹，可以在运行ossfs的时候指定allow_other参数： ossfs your_bucket your_mount_point -ourl=your_endpoint -o allow_other 为什么使用allow_other参数，仍然不能访问文件？ 注意：allow_other是赋予挂载目录其他用户访问的权限，不是里面的文件！如果您要更改文件夹中的文件，请用chmod命令。 allow_other默认赋予挂载目录777权限，我想让挂载目录的权限为770，该怎么办？ 可以通过umask来设置，参见这里。 Q: 如果要使挂载的文件夹(/tmp/ossfs)属于某个user: 方法一： 如果要使挂载的文件夹(/tmp/ossfs)属于某个user，则需要以user的身份创建挂载文件夹和使用ossfs： sudo -u user mkdir /tmp/ossfs sudo -u user ossfs bucket-name /tmp/ossfs 方法二： 首先通过id命令获得指定用户的uid/gid信息。例如获取www用户的uid/gid信息：id www；然后挂载时指定uid/gid参数： ossfs your_bucket your_mountpoint -ourl=your_url -ouid=your_uid -ogid=your_gid 注意：uid/gid都是数字。 Q: 我不是root用户，如何umount ossfs挂载的目录 fusermount -u your_mountpoint Q: 如何开机自动挂载ossfs？ Step 1 首先请参考使用说明，把bucket name，access key id/secret等信息写入/etc/passwd-ossfs，并将该文件权限修改为640。 echo your_bucket_name:your_access_key_id:your_access_key_secret > /etc/passwd-ossfs chmod 640 /etc/passwd-ossfs Step 2 接下来针对不同的系统版本，设置方式有所不同 Step 2A 通过fstab的方式自动mount（适用于ubuntu14.04, centos6.5） 在/etc/fstab中加入下面的命令 ossfs#your_bucket_name your_mount_point fuse _netdev,url=your_url,allow_other 0 0 其中上述命令中的your_xxx信息需要根据您的bucket name等信息填入。 保存/etc/fstab文件。执行mount -a命令，如果没有报错，则说明设置正常。 到这一步，ubuntu14.04就能自动挂载了。centos6.5还需要执行下面的命令： chkconfig netfs on Step 2B 通过开机自启动脚本mount（适用于centos7.0及以上的系统） 在/etc/init.d/目录下建立文件ossfs，把模板文件中的内容拷贝到这个新文件中。并将其中的your_xxx内容改成您自己的信息。 执行命令：chmod a+x /etc/init.d/ossfs 上述命令是把新建立的ossfs脚本赋予可执行权限。您可以执行该脚本，如果脚本文件内容无误，那么此时oss中的bucket已经挂载到您指定的目录下了。 执行命令：chkconfig ossfs on 上述命令是把ossfs启动脚本作为其他服务，开机自动启动。 好了，现在ossfs就可以开机自动挂载了。总结起来，如果您是ubuntu14.04和centos6.5，您需要执行Step 1 ＋ Step 2A；如果您是centos7.0系统，您需要执行Step 1 ＋ Step 2B。 Q: 遇到fusermount: failed to open current directory: Permission denied错误如何解决？ 这是fuse的一个bug，它要求当前用户对当前目录（非挂载目录）有读权限。解决的办法就是cd到一个有读权限的目录再运行ossfs命令 Q: 我需要以www用户挂载ossfs，此时如何设置开机自动挂载？ 参照上面的问题的解答，Step 1照做，对Step 2B稍加修改，修改/etc/init.d/ossfs中的命令为： sudo -u www ossfs your_bucket your_mountpoint -ourl=your_url 设置自启动脚本中允许使用sudo，编辑/etc/sudoers，将其中的Defaults requiretty这行改为#Defaults requiretty（注释掉） Q: 遇到fusermount: failed to open current directory: Permission denied错误如何解决？ 这是fuse的一个bug，它要求当前用户对当前目录（非挂载目录）有读权限。解决的办法就是cd到一个有读权限的目录再运行ossfs命令。 Q: 使用ECS挂载ossfs，如何避免因后台程序扫描文件而产生费用？ 程序扫描ossfs挂载的目录，会转换成向OSS的请求，如果请求次数很多，会产生费用（1分钱/1万次）。如果是updatedb，可以通过修改/etc/updatedb.conf让它跳过。具体做法是： 在PRUNEFS =后面加上fuse.ossfs 在PRUNEPATHS =后面加上挂载的目录 如何确定是哪个进程扫了我的目录？ 首先安装auditd: sudo apt-get install auditd 启动auditd: sudo service auditd start 设置监视挂载目录: auditctl -w /mnt/ossfs 在auditlog中可以查看是哪些进程访问了这个目录：ausearch -i | grep /mnt/ossfs Q: 使用ossfs上传到OSS的文件Content-Type全是”application/octet-stream”是怎么回事？ ossfs通过查询/etc/mime.types中的内容来确定文件的Content-Type，请检查这个文件是否存在，如果不存在，则需要添加： 对于ubuntu可以通过sudo apt-get install mime-support来添加 对于centos可以通过sudo yum install mailcap来添加 也可以手动添加，每种格式一行，每行格式为：application/javascript js Q: 如何使用supervisor启动ossfs？ 安装supervisor，在ubuntu中执行sudo apt-get install supervisor 建立一个目录，编辑ossfs的启动脚本：mkdir /root/ossfs_scripts vi /root/ossfs_scripts/start_ossfs.sh写入如下数据：# 卸载 fusermount -u /mnt/ossfs # 重新挂载，必须要增加-f参数运行ossfs，让ossfs在前台运行 exec ossfs my-bucket my-mount-point -ourl=my-oss-endpoint -f 编辑/etc/supervisor/supervisord.conf，在最后加入下面一段：[program:ossfs] command=bash /root/ossfs_scripts/start_ossfs.sh logfile=/var/log/ossfs.log log_stdout=true log_stderr=true logfile_maxbytes=1MB logfile_backups=10 运行supervisor：supervisordsupervisord 确认一切正常：ps aux | grep supervisor # 应该能看到supervisor进程 ps aux | grep ossfs # 应该能看到ossfs进程 kill -9 ossfs # 杀掉ossfs进程，supervisor应该会重启它, 不要使用killall, 因为killall发送SIGTERM，进程正常退出，supervisor不再去重新运行ossfs ps aux | grep ossfs # 应该能看到ossfs进程如果出错，请检查/var/log/supervisor/supervisord.log和/var/log/ossfs.log。 Q: 遇到”fuse: warning: library too old, some operations may not work”怎么办？ 出现的原因是：ossfs编译时所使用的libfuse版本 比运行时链接到的libfuse版本高。这往往是用户自行安装了libfuse导致的。使用我们提供的rpm包安装ossfs，无需再安装libfuse。 在CentOS-5.x和CentOS-6.x上我们提供的rpm包里包含了libfuse-2.8.4，如果在运行的时候环境中有libfuse-2.8.3，并且ossfs被链接到了旧版本的fuse上，就会出现上述warning。 如何确认ossfs运行时链接的fuse版本？ 运行ldd $(which ossfs) | grep fuse 例如结果是”/lib64/libfuse.so.2”，那么通过ls -l /lib64/libfuse*可以看到fuse的版本 如何让ossfs链接到正确的版本？ 首先通过rpm -ql ossfs | grep fuse找到libfuse的目录 例如结果是”/usr/lib/libfuse.so.2”，则通过LD_LIBRARY_PATH=/usr/lib ossfs …运行ossfs 我能忽略这个WARNING吗？ 最好不要，见这个bug Q: 为什么用ossfs看到的文件信息（例如大小）与其他工具看到的不一致？ 因为ossfs默认会缓存文件的元信息（包括大小/权限等），这样就不需要每次ls的时候向OSS发送请求，加快速度。 如果用户通过其他程序（例如SDK/官网控制台/osscmd等）对文件进行了修改，那么有可能在ossfs中看到的文件信息 没有及时更新。 如果想禁止ossfs的缓存，那么可以在挂载的时候加上如下参数：-omax_stat_cache_size=0

详细解答可以参考官方帮助文档 Q: ossfs适合什么样的程序？ ossfs能把oss bucket挂载到本地，如果您使用的软件没有支持OSS，但您又想让数据能自动同步到OSS，那么ossfs是很好的选择。 Q: ossfs有什么局限性？ 由于数据需要经过网络同步到云端，ossfs在性能和功能上可能与本地文件系统有差距。如果您想让数据库等对io要求很高的应用跑在ossfs挂载的盘上，请慎重考虑。和本地文件系统具体差异： 随机或者追加写文件会导致整个文件的重写。 元数据操作，例如list directory，性能较差，因为需要远程访问OSS服务器。 文件/文件夹的rename操作不是原子的。 多个客户端挂载同一个oss bucket时，依赖用户自行协调各个客户端的行为。例如避免多个客户端写同一个文件等等。 不支持hard link。 Q: ossfs一定要阿里云的机器才能用么？ ossfs不限制一定要阿里云的内网才可以使用，外网机器依然可以使用。 Q: ossfs能不能同时挂载多个OSS bucket？ 可以的，在passwd-ossfs文件中写入多个OSS配置信息即可。支持不同帐号的OSS。 Q: 我在yum/apt-get安装ossfs，遇到conflicts with file from package fuse-devel的错误，请问是怎么回事？ 您的系统中存在老版本的fuse，请先使用相关的包管理器卸载，再重新安装ossfs。 Q: ossfs工作不正常，如何debug？ 您可以使用在挂载时，加上-d -o f2参数，ossfs会把日志写入到系统日志中。在centos系统中，在/var/log/messages中。 您也可以在挂载时使用-f -d -o f2参数，ossfs会把日志输出到屏幕上。 Q: 为什么我在mount时遇到 ossfs: unable to access MOUNTPOINT /tmp/ossfs: Transport endpoint is not connected这样的错误？ 请先umount对应的目录。 请检查您在使用ossfs挂载时，填入的url参数是否正确，是否和bucket/access key id/access key secret匹配。 特别注意：url中不包含bucket的名字。例如：您在oss控制台中看到bucket的域名是这样的：ossfs-test-1.oss-cn-hangzhou.aliyuncs.com。那么填入的url则是：http://oss-cn-hangzhou.aliyuncs.com。 Q: ossfs提示ossfs: unable to access MOUNTPOINT /tmp/odat: No such file or directory 这是您未创建该目录导致的，在挂载前需要创建对应目录。 Q: 我把bucket挂载到本地后，ls目录，却收到operation not permitted错误，这是为什么？ 请检查您的bucket中，是否包含目录名含有不可见字符的OSS object。文件系统对文件/目录名有更严格的限制，因此会收到上述错误。使用其他工具对这些object重命名后，ls就能正确显示目录内容了。 Q: 我的一个目录下有非常多的文件，为什么ls该目录很慢？ 假设一个目录下有n个文件，那么ls该目录至少需要n次OSS http requests。在文件非常多的时候，这可能造成严重的性能问题。 您可以采用下面两个办法优化： 通过-omax_stat_cache_size=xxx参数增大stat cache的size，这样第一次ls会较慢，但是后续的ls就快了，因为文件的元数据都在本地cache中。默认这个值是1000，大约消耗4MB内存，请根据您机器内存大小调整为合适的值。 使用ls -f命令，这个命令会消除与OSS的n次http请求。 具体参见issue 13。 Q: ossfs挂载时如何设置权限？ 如果要允许其他用户访问挂载文件夹，可以在运行ossfs的时候指定allow_other参数： ossfs your_bucket your_mount_point -ourl=your_endpoint -o allow_other 为什么使用allow_other参数，仍然不能访问文件？ 注意：allow_other是赋予挂载目录其他用户访问的权限，不是里面的文件！如果您要更改文件夹中的文件，请用chmod命令。 allow_other默认赋予挂载目录777权限，我想让挂载目录的权限为770，该怎么办？ 可以通过umask来设置，参见这里。 Q: 如果要使挂载的文件夹(/tmp/ossfs)属于某个user: 方法一： 如果要使挂载的文件夹(/tmp/ossfs)属于某个user，则需要以user的身份创建挂载文件夹和使用ossfs： sudo -u user mkdir /tmp/ossfs sudo -u user ossfs bucket-name /tmp/ossfs 方法二： 首先通过id命令获得指定用户的uid/gid信息。例如获取www用户的uid/gid信息：id www；然后挂载时指定uid/gid参数： ossfs your_bucket your_mountpoint -ourl=your_url -ouid=your_uid -ogid=your_gid 注意：uid/gid都是数字。 Q: 我不是root用户，如何umount ossfs挂载的目录 fusermount -u your_mountpoint Q: 如何开机自动挂载ossfs？ Step 1 首先请参考使用说明，把bucket name，access key id/secret等信息写入/etc/passwd-ossfs，并将该文件权限修改为640。 echo your_bucket_name:your_access_key_id:your_access_key_secret > /etc/passwd-ossfs chmod 640 /etc/passwd-ossfs Step 2 接下来针对不同的系统版本，设置方式有所不同 Step 2A 通过fstab的方式自动mount（适用于ubuntu14.04, centos6.5） 在/etc/fstab中加入下面的命令 ossfs#your_bucket_name your_mount_point fuse _netdev,url=your_url,allow_other 0 0 其中上述命令中的your_xxx信息需要根据您的bucket name等信息填入。 保存/etc/fstab文件。执行mount -a命令，如果没有报错，则说明设置正常。 到这一步，ubuntu14.04就能自动挂载了。centos6.5还需要执行下面的命令： chkconfig netfs on Step 2B 通过开机自启动脚本mount（适用于centos7.0及以上的系统） 在/etc/init.d/目录下建立文件ossfs，把模板文件中的内容拷贝到这个新文件中。并将其中的your_xxx内容改成您自己的信息。 执行命令：chmod a+x /etc/init.d/ossfs 上述命令是把新建立的ossfs脚本赋予可执行权限。您可以执行该脚本，如果脚本文件内容无误，那么此时oss中的bucket已经挂载到您指定的目录下了。 执行命令：chkconfig ossfs on 上述命令是把ossfs启动脚本作为其他服务，开机自动启动。 好了，现在ossfs就可以开机自动挂载了。总结起来，如果您是ubuntu14.04和centos6.5，您需要执行Step 1 ＋ Step 2A；如果您是centos7.0系统，您需要执行Step 1 ＋ Step 2B。 Q: 遇到fusermount: failed to open current directory: Permission denied错误如何解决？ 这是fuse的一个bug，它要求当前用户对当前目录（非挂载目录）有读权限。解决的办法就是cd到一个有读权限的目录再运行ossfs命令 Q: 我需要以www用户挂载ossfs，此时如何设置开机自动挂载？ 参照上面的问题的解答，Step 1照做，对Step 2B稍加修改，修改/etc/init.d/ossfs中的命令为： sudo -u www ossfs your_bucket your_mountpoint -ourl=your_url 设置自启动脚本中允许使用sudo，编辑/etc/sudoers，将其中的Defaults requiretty这行改为#Defaults requiretty（注释掉） Q: 遇到fusermount: failed to open current directory: Permission denied错误如何解决？ 这是fuse的一个bug，它要求当前用户对当前目录（非挂载目录）有读权限。解决的办法就是cd到一个有读权限的目录再运行ossfs命令。 Q: 使用ECS挂载ossfs，如何避免因后台程序扫描文件而产生费用？ 程序扫描ossfs挂载的目录，会转换成向OSS的请求，如果请求次数很多，会产生费用（1分钱/1万次）。如果是updatedb，可以通过修改/etc/updatedb.conf让它跳过。具体做法是： 在PRUNEFS =后面加上fuse.ossfs 在PRUNEPATHS =后面加上挂载的目录 如何确定是哪个进程扫了我的目录？ 首先安装auditd: sudo apt-get install auditd 启动auditd: sudo service auditd start 设置监视挂载目录: auditctl -w /mnt/ossfs 在auditlog中可以查看是哪些进程访问了这个目录：ausearch -i | grep /mnt/ossfs Q: 使用ossfs上传到OSS的文件Content-Type全是”application/octet-stream”是怎么回事？ ossfs通过查询/etc/mime.types中的内容来确定文件的Content-Type，请检查这个文件是否存在，如果不存在，则需要添加： 对于ubuntu可以通过sudo apt-get install mime-support来添加 对于centos可以通过sudo yum install mailcap来添加 也可以手动添加，每种格式一行，每行格式为：application/javascript js Q: 如何使用supervisor启动ossfs？ 安装supervisor，在ubuntu中执行sudo apt-get install supervisor 建立一个目录，编辑ossfs的启动脚本：mkdir /root/ossfs_scripts vi /root/ossfs_scripts/start_ossfs.sh写入如下数据：# 卸载 fusermount -u /mnt/ossfs # 重新挂载，必须要增加-f参数运行ossfs，让ossfs在前台运行 exec ossfs my-bucket my-mount-point -ourl=my-oss-endpoint -f 编辑/etc/supervisor/supervisord.conf，在最后加入下面一段：[program:ossfs] command=bash /root/ossfs_scripts/start_ossfs.sh logfile=/var/log/ossfs.log log_stdout=true log_stderr=true logfile_maxbytes=1MB logfile_backups=10 运行supervisor：supervisordsupervisord 确认一切正常：ps aux | grep supervisor # 应该能看到supervisor进程 ps aux | grep ossfs # 应该能看到ossfs进程 kill -9 ossfs # 杀掉ossfs进程，supervisor应该会重启它, 不要使用killall, 因为killall发送SIGTERM，进程正常退出，supervisor不再去重新运行ossfs ps aux | grep ossfs # 应该能看到ossfs进程如果出错，请检查/var/log/supervisor/supervisord.log和/var/log/ossfs.log。 Q: 遇到”fuse: warning: library too old, some operations may not work”怎么办？ 出现的原因是：ossfs编译时所使用的libfuse版本 比运行时链接到的libfuse版本高。这往往是用户自行安装了libfuse导致的。使用我们提供的rpm包安装ossfs，无需再安装libfuse。 在CentOS-5.x和CentOS-6.x上我们提供的rpm包里包含了libfuse-2.8.4，如果在运行的时候环境中有libfuse-2.8.3，并且ossfs被链接到了旧版本的fuse上，就会出现上述warning。 如何确认ossfs运行时链接的fuse版本？ 运行ldd $(which ossfs) | grep fuse 例如结果是”/lib64/libfuse.so.2”，那么通过ls -l /lib64/libfuse*可以看到fuse的版本 如何让ossfs链接到正确的版本？ 首先通过rpm -ql ossfs | grep fuse找到libfuse的目录 例如结果是”/usr/lib/libfuse.so.2”，则通过LD_LIBRARY_PATH=/usr/lib ossfs …运行ossfs 我能忽略这个WARNING吗？ 最好不要，见这个bug Q: 为什么用ossfs看到的文件信息（例如大小）与其他工具看到的不一致？ 因为ossfs默认会缓存文件的元信息（包括大小/权限等），这样就不需要每次ls的时候向OSS发送请求，加快速度。 如果用户通过其他程序（例如SDK/官网控制台/osscmd等）对文件进行了修改，那么有可能在ossfs中看到的文件信息 没有及时更新。 如果想禁止ossfs的缓存，那么可以在挂载的时候加上如下参数：-omax_stat_cache_size=0

详细解答可以参考官方帮助文档 Q: ossfs适合什么样的程序？ ossfs能把oss bucket挂载到本地，如果您使用的软件没有支持OSS，但您又想让数据能自动同步到OSS，那么ossfs是很好的选择。 Q: ossfs有什么局限性？ 由于数据需要经过网络同步到云端，ossfs在性能和功能上可能与本地文件系统有差距。如果您想让数据库等对io要求很高的应用跑在ossfs挂载的盘上，请慎重考虑。和本地文件系统具体差异： 随机或者追加写文件会导致整个文件的重写。 元数据操作，例如list directory，性能较差，因为需要远程访问OSS服务器。 文件/文件夹的rename操作不是原子的。 多个客户端挂载同一个oss bucket时，依赖用户自行协调各个客户端的行为。例如避免多个客户端写同一个文件等等。 不支持hard link。 Q: ossfs一定要阿里云的机器才能用么？ ossfs不限制一定要阿里云的内网才可以使用，外网机器依然可以使用。 Q: ossfs能不能同时挂载多个OSS bucket？ 可以的，在passwd-ossfs文件中写入多个OSS配置信息即可。支持不同帐号的OSS。 Q: 我在yum/apt-get安装ossfs，遇到conflicts with file from package fuse-devel的错误，请问是怎么回事？ 您的系统中存在老版本的fuse，请先使用相关的包管理器卸载，再重新安装ossfs。 Q: ossfs工作不正常，如何debug？ 您可以使用在挂载时，加上-d -o f2参数，ossfs会把日志写入到系统日志中。在centos系统中，在/var/log/messages中。 您也可以在挂载时使用-f -d -o f2参数，ossfs会把日志输出到屏幕上。 Q: 为什么我在mount时遇到 ossfs: unable to access MOUNTPOINT /tmp/ossfs: Transport endpoint is not connected这样的错误？ 请先umount对应的目录。 请检查您在使用ossfs挂载时，填入的url参数是否正确，是否和bucket/access key id/access key secret匹配。 特别注意：url中不包含bucket的名字。例如：您在oss控制台中看到bucket的域名是这样的：ossfs-test-1.oss-cn-hangzhou.aliyuncs.com。那么填入的url则是：http://oss-cn-hangzhou.aliyuncs.com。 Q: ossfs提示ossfs: unable to access MOUNTPOINT /tmp/odat: No such file or directory 这是您未创建该目录导致的，在挂载前需要创建对应目录。 Q: 我把bucket挂载到本地后，ls目录，却收到operation not permitted错误，这是为什么？ 请检查您的bucket中，是否包含目录名含有不可见字符的OSS object。文件系统对文件/目录名有更严格的限制，因此会收到上述错误。使用其他工具对这些object重命名后，ls就能正确显示目录内容了。 Q: 我的一个目录下有非常多的文件，为什么ls该目录很慢？ 假设一个目录下有n个文件，那么ls该目录至少需要n次OSS http requests。在文件非常多的时候，这可能造成严重的性能问题。 您可以采用下面两个办法优化： 通过-omax_stat_cache_size=xxx参数增大stat cache的size，这样第一次ls会较慢，但是后续的ls就快了，因为文件的元数据都在本地cache中。默认这个值是1000，大约消耗4MB内存，请根据您机器内存大小调整为合适的值。 使用ls -f命令，这个命令会消除与OSS的n次http请求。 具体参见issue 13。 Q: ossfs挂载时如何设置权限？ 如果要允许其他用户访问挂载文件夹，可以在运行ossfs的时候指定allow_other参数： ossfs your_bucket your_mount_point -ourl=your_endpoint -o allow_other 为什么使用allow_other参数，仍然不能访问文件？ 注意：allow_other是赋予挂载目录其他用户访问的权限，不是里面的文件！如果您要更改文件夹中的文件，请用chmod命令。 allow_other默认赋予挂载目录777权限，我想让挂载目录的权限为770，该怎么办？ 可以通过umask来设置，参见这里。 Q: 如果要使挂载的文件夹(/tmp/ossfs)属于某个user: 方法一： 如果要使挂载的文件夹(/tmp/ossfs)属于某个user，则需要以user的身份创建挂载文件夹和使用ossfs： sudo -u user mkdir /tmp/ossfs sudo -u user ossfs bucket-name /tmp/ossfs 方法二： 首先通过id命令获得指定用户的uid/gid信息。例如获取www用户的uid/gid信息：id www；然后挂载时指定uid/gid参数： ossfs your_bucket your_mountpoint -ourl=your_url -ouid=your_uid -ogid=your_gid 注意：uid/gid都是数字。 Q: 我不是root用户，如何umount ossfs挂载的目录 fusermount -u your_mountpoint Q: 如何开机自动挂载ossfs？ Step 1 首先请参考使用说明，把bucket name，access key id/secret等信息写入/etc/passwd-ossfs，并将该文件权限修改为640。 echo your_bucket_name:your_access_key_id:your_access_key_secret > /etc/passwd-ossfs chmod 640 /etc/passwd-ossfs Step 2 接下来针对不同的系统版本，设置方式有所不同 Step 2A 通过fstab的方式自动mount（适用于ubuntu14.04, centos6.5） 在/etc/fstab中加入下面的命令 ossfs#your_bucket_name your_mount_point fuse _netdev,url=your_url,allow_other 0 0 其中上述命令中的your_xxx信息需要根据您的bucket name等信息填入。 保存/etc/fstab文件。执行mount -a命令，如果没有报错，则说明设置正常。 到这一步，ubuntu14.04就能自动挂载了。centos6.5还需要执行下面的命令： chkconfig netfs on Step 2B 通过开机自启动脚本mount（适用于centos7.0及以上的系统） 在/etc/init.d/目录下建立文件ossfs，把模板文件中的内容拷贝到这个新文件中。并将其中的your_xxx内容改成您自己的信息。 执行命令：chmod a+x /etc/init.d/ossfs 上述命令是把新建立的ossfs脚本赋予可执行权限。您可以执行该脚本，如果脚本文件内容无误，那么此时oss中的bucket已经挂载到您指定的目录下了。 执行命令：chkconfig ossfs on 上述命令是把ossfs启动脚本作为其他服务，开机自动启动。 好了，现在ossfs就可以开机自动挂载了。总结起来，如果您是ubuntu14.04和centos6.5，您需要执行Step 1 ＋ Step 2A；如果您是centos7.0系统，您需要执行Step 1 ＋ Step 2B。 Q: 遇到fusermount: failed to open current directory: Permission denied错误如何解决？ 这是fuse的一个bug，它要求当前用户对当前目录（非挂载目录）有读权限。解决的办法就是cd到一个有读权限的目录再运行ossfs命令 Q: 我需要以www用户挂载ossfs，此时如何设置开机自动挂载？ 参照上面的问题的解答，Step 1照做，对Step 2B稍加修改，修改/etc/init.d/ossfs中的命令为： sudo -u www ossfs your_bucket your_mountpoint -ourl=your_url 设置自启动脚本中允许使用sudo，编辑/etc/sudoers，将其中的Defaults requiretty这行改为#Defaults requiretty（注释掉） Q: 遇到fusermount: failed to open current directory: Permission denied错误如何解决？ 这是fuse的一个bug，它要求当前用户对当前目录（非挂载目录）有读权限。解决的办法就是cd到一个有读权限的目录再运行ossfs命令。 Q: 使用ECS挂载ossfs，如何避免因后台程序扫描文件而产生费用？ 程序扫描ossfs挂载的目录，会转换成向OSS的请求，如果请求次数很多，会产生费用（1分钱/1万次）。如果是updatedb，可以通过修改/etc/updatedb.conf让它跳过。具体做法是： 在PRUNEFS =后面加上fuse.ossfs 在PRUNEPATHS =后面加上挂载的目录 如何确定是哪个进程扫了我的目录？ 首先安装auditd: sudo apt-get install auditd 启动auditd: sudo service auditd start 设置监视挂载目录: auditctl -w /mnt/ossfs 在auditlog中可以查看是哪些进程访问了这个目录：ausearch -i | grep /mnt/ossfs Q: 使用ossfs上传到OSS的文件Content-Type全是”application/octet-stream”是怎么回事？ ossfs通过查询/etc/mime.types中的内容来确定文件的Content-Type，请检查这个文件是否存在，如果不存在，则需要添加： 对于ubuntu可以通过sudo apt-get install mime-support来添加 对于centos可以通过sudo yum install mailcap来添加 也可以手动添加，每种格式一行，每行格式为：application/javascript js Q: 如何使用supervisor启动ossfs？ 安装supervisor，在ubuntu中执行sudo apt-get install supervisor 建立一个目录，编辑ossfs的启动脚本：mkdir /root/ossfs_scripts vi /root/ossfs_scripts/start_ossfs.sh写入如下数据：# 卸载 fusermount -u /mnt/ossfs # 重新挂载，必须要增加-f参数运行ossfs，让ossfs在前台运行 exec ossfs my-bucket my-mount-point -ourl=my-oss-endpoint -f 编辑/etc/supervisor/supervisord.conf，在最后加入下面一段：[program:ossfs] command=bash /root/ossfs_scripts/start_ossfs.sh logfile=/var/log/ossfs.log log_stdout=true log_stderr=true logfile_maxbytes=1MB logfile_backups=10 运行supervisor：supervisordsupervisord 确认一切正常：ps aux | grep supervisor # 应该能看到supervisor进程 ps aux | grep ossfs # 应该能看到ossfs进程 kill -9 ossfs # 杀掉ossfs进程，supervisor应该会重启它, 不要使用killall, 因为killall发送SIGTERM，进程正常退出，supervisor不再去重新运行ossfs ps aux | grep ossfs # 应该能看到ossfs进程如果出错，请检查/var/log/supervisor/supervisord.log和/var/log/ossfs.log。 Q: 遇到”fuse: warning: library too old, some operations may not work”怎么办？ 出现的原因是：ossfs编译时所使用的libfuse版本 比运行时链接到的libfuse版本高。这往往是用户自行安装了libfuse导致的。使用我们提供的rpm包安装ossfs，无需再安装libfuse。 在CentOS-5.x和CentOS-6.x上我们提供的rpm包里包含了libfuse-2.8.4，如果在运行的时候环境中有libfuse-2.8.3，并且ossfs被链接到了旧版本的fuse上，就会出现上述warning。 如何确认ossfs运行时链接的fuse版本？ 运行ldd $(which ossfs) | grep fuse 例如结果是”/lib64/libfuse.so.2”，那么通过ls -l /lib64/libfuse*可以看到fuse的版本 如何让ossfs链接到正确的版本？ 首先通过rpm -ql ossfs | grep fuse找到libfuse的目录 例如结果是”/usr/lib/libfuse.so.2”，则通过LD_LIBRARY_PATH=/usr/lib ossfs …运行ossfs 我能忽略这个WARNING吗？ 最好不要，见这个bug Q: 为什么用ossfs看到的文件信息（例如大小）与其他工具看到的不一致？ 因为ossfs默认会缓存文件的元信息（包括大小/权限等），这样就不需要每次ls的时候向OSS发送请求，加快速度。 如果用户通过其他程序（例如SDK/官网控制台/osscmd等）对文件进行了修改，那么有可能在ossfs中看到的文件信息 没有及时更新。 如果想禁止ossfs的缓存，那么可以在挂载的时候加上如下参数：-omax_stat_cache_size=0