给卖假性药的做网站一般要判多久,网站备案成功后怎么建设,网上学编程的有哪些比较好的网站,电子商务网站建设的范围是什么意思相信在实际工作中#xff0c;提及性能优化你会想到代码优化#xff0c;但是实际上有些性能优化可能只需要调整一些配置参数就可以搞定了。为什么这么说呢#xff1f;我给你举几个例子#xff1a;
你可以调整配置的超时时间让请求快速失败#xff0c;防止系统的雪崩#…相信在实际工作中提及性能优化你会想到代码优化但是实际上有些性能优化可能只需要调整一些配置参数就可以搞定了。为什么这么说呢我给你举几个例子
你可以调整配置的超时时间让请求快速失败防止系统的雪崩提升系统的可用性
你还可以调整 HTTP 客户端连接池的大小来提升调用第三方 HTTP 服务的并行处理能力从而提升系统的性能。
你可以认为配置是管理你系统的工具在你的垂直电商系统中一定会有非常多的配置项比如数据库的地址、请求 HTTP 服务的域名、本地内存最大缓存数量等等。
那么你要如何对这些配置项做管理呢管理的过程中要注意哪些事情呢
如何对配置进行管理
配置管理由来已久在 Linux 系统中就提供了大量的配置项你可以根据自身业务的实际情况动态地对系统功能做调整。比如你可以通过修改 dirty_writeback_centisecs 参数的数值调整 Page Cache 中脏数据刷新到磁盘上的频率你也可以通过修改 tcp_max_syn_backlog 参数的值来调整未建立连接队列的长度。而你既可以通过修改配置文件并且重启服务器来让配置生效也可以通过 sysctl 命令来动态地调整让配置即时生效。
那么在开发应用的时候都有哪些管理配置的方式呢我觉得主要有两种
一种是通过配置文件来管理
另一种是使用配置中心来管理。
以电商系统为例你和你的团队在刚开始开发垂直电商系统时为了加快产品的研发速度大概率不会注意配置管理的问题会自然而然地把配置项和代码写在一起。但是随着配置项越来越多为了更好地对配置项进行管理同时避免修改配置项后还要重新对代码做编译你选择把配置项拆分成独立的文件文件可以是 properties 格式、xml 格式或 yaml 格式。不过这些文件还是会和工程一起打包部署只是更改配置后不需要重新编译代码了。
随后你很快发现了一个问题虽然把配置拆分了出来但是由于配置还是和代码打包在一起如果要更改一个配置还是需要重新打包这样无疑会增加打包的时间。于是你考虑把配置写到单独的目录中这样修改配置就不需要再重新打包了不过由于配置并不能够实时生效所以想让配置生效还是需要重启服务。
我们一般使用的基础组件比如 Tomcat、Nginx都是采用上面这种配置文件的方式来管理配置项的而在 Linux 系统中我提到的 tcp_max_syn_backlog 就可以配置在 /etc/sysctl.conf 中。
这里我需要强调一点我们通常会把配置文件存储的目录标准化为特定的目录。比如都配置成 /data/confs 目录然后把配置项使用 Git 等代码仓库管理起来。这样在增加新的机器时在机器初始化脚本中只需要创建这个目录再从 Git 中拉取配置就可以了。这是一个标准化的过程可以避免在启动应用时忘记部署配置文件。
再进一步说如果你的服务是多机房部署的那么不同机房的配置项中有可能是相同的也有可能是不同的。这时候你需要将相同的配置项放置在一个目录中给多个机房共用再将不同的配置项放置在以机房名为名称的目录中。在读取配置的时候应该优先读取机房的配置再读取公共配置这样可以减少配置文件中的配置项的数量。
我列了一个典型目录配置如果你的系统也使用文件来管理配置可以参考一下。
/data/confs/common/commerce //电商业务的公共配置
/data/confs/commerce-zw //电商业务兆维机房配置
/data/confs/commerce-yz //电商业务亦庄机房配置/data/confs/common/community //社区业务的公共配置
/data/confs/community-zw //社区业务兆维机房配置
/data/confs/community-yz //社区业务亦庄机房配置
那么这是不是配置管理的最终形态呢当然不是你不要忘了把配置放在文件中的方式还存在的问题我上面也提到过了那就是我们必须将服务重启后才能让配置生效。有没有一种方法可以在不重启应用的前提下也能让配置生效呢这就需要配置中心帮助我们实现了。
配置中心是如何实现的
配置中心可以算是微服务架构中的一个标配组件了。业界也提供了多种开源方案供你选择比较出名的有携程开源的 Apollo、百度开源的 Disconf、360 开源的 QConf、Spring Cloud 的组件 Spring Cloud Config 等等。
在我看来Apollo 支持不同环境不同集群的配置有完善的管理功能支持灰度发布、更改热发布等功能在所有配置中心中功能比较齐全推荐你使用。
那么配置中心的组件在实现上有哪些关键的点呢如果你想对配置中心组件有更强的把控力想要自行研发一套符合自己业务场景的组件又要如何入手呢
配置信息如何存储
其实配置中心和注册中心非常类似其核心的功能就是配置项的存储和读取。所以在设计配置中心的服务端时我们需要选择合适的存储组件来存储大量的配置信息这里可选择的组件有很多。
事实上不同的开源配置中心也使用了不同的组件比如 Disconf、Apollo 使用的是 MySQLQConf 使用的是 ZooKeeper。我之前维护和使用的配置中心就会使用不同的存储组件比如微博的配置中心使用 Redis 来存储信息而美图用的是 Etcd。
无论使用哪一种存储组件你所要做的就是规范配置项在其中的存储结构。比如我之前使用的配置中心用 Etcd 作为存储组件支持存储全局配置、机房配置和节点配置。其中节点配置优先级高于机房配置机房配置优先级高于全局配置。也就是说我们会优先读取节点的配置如果节点配置不存在再读取机房配置最后读取全局配置。它们的存储路径如下
/confs/global/{env}/{project}/{service}/{version}/{module}/{key} //全局配置
/confs/regions/{env}/{project}/{service}/{version}/{region}/{module}/{key} //机房配置 /confs/nodes/{env}/{project}/{service}/{version}/{region}/{node}/{module}/{key} //节点配置
变更推送如何实现
配置信息存储之后我们需要考虑如何将配置的变更推送给服务端这样就可以实现配置的动态变更也就是说不需要重启服务器就能让配置生效了。而我们一般会有两种思路来实现变更推送一种是轮询查询的方式一种是长连推送的方式。
轮询查询很简单就是应用程序向配置中心客户端注册一个监听器配置中心的客户端定期地比如 1 分钟查询所需要的配置是否有变化如果有变化则通知触发监听器让应用程序得到变更通知。
这里有一个需要注意的点如果有很多应用服务器都去轮询拉取配置由于返回的配置项可能会很大那么配置中心服务的带宽就会成为瓶颈。为了解决这个问题我们会给配置中心的每一个配置项多存储一个根据配置项计算出来的 MD5 值。
配置项一旦变化这个 MD5 值也会随之改变。配置中心客户端在获取到配置的同时也会获取到配置的 MD5 值并且存储起来。那么在轮询查询的时候需要先确认存储的 MD5 值和配置中心的 MD5 是不是一致的。如果不一致这就说明配置中心里存储的配置项有变化然后才会从配置中心拉取最新的配置。
由于配置中心里存储的配置项变化的几率不大所以使用这种方式后每次轮询请求就只是返回一个 MD5 值可以大大地减少配置中心服务器的带宽。 另一种长连的方式它的逻辑是在配置中心服务端保存每个连接关注的配置项列表。这样当配置中心感知到配置变化后就可以通过这个连接把变更的配置推送给客户端。这种方式需要保持长连也需要保存连接和配置的对应关系实现上要比轮询的方式复杂一些但是相比轮询方式来说能够更加实时地获取配置变更的消息。
而在我看来配置服务中存储的配置变更频率不高所以对于实时性要求不高但是期望实现上能够足够简单那么如果选择自研配置中心的话可以考虑使用轮询的方式。
如何保证配置中心高可用
除了变更通知以外在配置中心实现中另外一个比较关键的点在于如何保证它的可用性。因为对于配置中心来说可用性的重要程度要远远大于性能。
我们一般会在服务器启动时从配置中心中获取配置如果配置获取的性能不高那么外在的表现也只是应用启动时间慢了对于业务的影响不大。但是如果获取不到配置很可能会导致启动失败。
比如我们把数据库的地址存储在了配置中心里如果配置中心宕机导致我们无法获取数据库的地址那么自然应用程序就会启动失败。因此我们的诉求是让配置中心“旁路化”。也就是说即使配置中心宕机或者配置中心依赖的存储宕机我们仍然能够保证应用程序是可以启动的。那么这是如何实现的呢
我们一般会在配置中心的客户端上增加两级缓存第一级缓存是内存的缓存另外一级缓存是文件的缓存。
配置中心客户端在获取到配置信息后会同时把配置信息同步地写入到内存缓存并且异步地写入到文件缓存中。内存缓存的作用是降低客户端和配置中心的交互频率提升配置获取的性能而文件的缓存的作用就是灾备当应用程序重启时一旦配置中心发生故障那么应用程序就会优先使用文件中的配置这样虽然无法得到配置的变更消息因为配置中心已经宕机了但是应用程序还是可以启动起来的算是一种降级的方案。
课程小结
了解了系统开发的过程中我们是如何管理大量的配置项的需要了解的重点是
配置存储是分级的有公共配置有个性的配置一般个性配置会覆盖公共配置这样可以减少存储配置项的数量
配置中心可以提供配置变更通知的功能可以实现配置的热更新
配置中心关注的性能指标中可用性的优先级是高于性能的一般我们会要求配置中心的可用性达到 99.999%甚至会是 99.9999%。
这里你需要注意的是并不是所有的配置项都需要使用配置中心来存储如果你的项目还是使用文件方式来管理配置那么你只需要将类似超时时间等需要动态调整的配置迁移到配置中心就可以了。对于像是数据库地址依赖第三方请求的地址这些基本不会发生变化的配置项可以依然使用文件的方式来管理这样可以大大地减少配置迁移的成本。
