技术架构演进中的思考点.docxVIP

技术架构演进中的思考点 2021-03-29 网站技术架构为什么会演进 我个人总结出来我们的技术架构演进的两种驱动力，驱动着我们为什么演进网站的技术架构： 1. 内在驱动力：我们期望把当前的业务做得更好，开发更多新业务 2. 外在驱动力：用户量的上升、用户品种的多样化 这两种驱动力不是独立的，更多时候是并行的。我想淘宝就是两种驱动力并行驱动的结果。 演进的缘由很简约。但是在什么时机我们就应当演进网站的技术架构了，以及如何演进？面对这些问题，说实话，我没有任何阅历，再说现实中每家企业当时都面临的问题都不一样，所以，我很难从阅历中总结出什么是演进的时机。 但是我可以从另一个角度切入这个问题：争辩网站内外结构，找到这些结构可能消灭的问题点，晓得或者预见到问题点了，你当然就晓得应当怎样演进了。类似于你了解了 PC 机的结构，你也就晓得什么时候要加内存了，什么时候要加硬盘了。 那么我们先看看网站的外部结构： 外部结构中，我们可以看由以下几个部分构成： U：代表用户群。当用户群变了，我们的网站如何演进？用户群的分析，我目前能晓得的维度有：数量，品种，地理位置（区域）。 N：代表网络环境。网络环境在每个地区都不同。你可以想像我们为什么需要 CDN。当我们期望每个区域的用户都能得到好的体验，我们的网站如何演进？ S：代表平安。就是我们要平安到什么程度？这与网站当前所处阶段及你网站的性质有关。 C：代表我们的网站。属于内部结构 网站的内部结构： 内部结构的组成： A：应用服务。 D：数据服务 总结下来就是我们在考虑网站能否应当演进了或者如何演进时，这些组成部分为我们供应了考虑问题的基准。 那么我们为什么不一开头就把网站设计成“大型”的。李才智在后记里写到：“不要企图去设计一个大型网站”，“缘由是互联网进展运转有其本人的规律，短暂的互联网历史已经一再证明这种企图行不通”。还说了：“大型网站不是设计出来的，而是逐渐演化出来的”。对于最终这句话，我需要提示下：“不是设计出来的”并不代表“任凭设计”。 对于“大型网站的设计”，我个人的看法是现在我们的有“云”了，计算是可以买的，只需我们的设计能顺应“云”，我是不是就可以一开头就设计大型网站了？ 演进的过程会遇到什么问题 - 最后 从一个小网站说起。一台服务器也就足够了。 - 数据服务与应用服务分别 越来越多的用户代表着越来越多的数据，一台服务器已经满足不了。我们将数据服务和应用服务分别，给应用服务器配置更好的 CPU，内存。而给数据服务器配置更好更大的硬盘。 - 使用缓存 由于 80% 的业务访问都集中在 20% 的数据上，假如我们能将这部分数据缓存下来，功能一下子就上来了。而缓存又分为两种：本地缓存和近程分布式缓存。具体使用哪种？还是两种都用，我目前不晓得。 这里有一个问题：应当缓存哪些数据？应当有一些准绳的吧。 - 使用服务器集群 当这台服务器的处理力量达到上限时，它就会成为瓶颈。虽然你是可以通过购买更强大的硬件，但总会有上限。这时，我们就需要服务器的集群。这时，就必需加个新东西：负载均衡调度服务器。 但是，使用服务器集群时，需要考虑一个问题：Session 的管理问题。Session 的管理有以下几种方式： Session Sticky：打个比方就是假如我们每次吃饭都要保证我们用的是本人的碗筷，而只需我们在一家饭店里存着我们的碗筷，只需我们每次去这家饭店吃饭就好了。 这种方式的问题： 1. 一台服务器重启，上面的 session 都没了 2. 负载均衡器成了无形态的机器，要实现容灾会有麻烦 Session 复制：就像我们在全部的饭店里都存一份本人的碗筷。不适合做大规模集群，适合机器不多的情况 这种方案的问题： 1. 应用服务器间带宽问题 2. 大量用户在线时，占用内存过多 基于 Cookie：类似于每次吃饭都把本人的碗筷带上 这种方案的问题： 1. Cookie 的长度限制 2. 平安性 3. 数据中心外部带宽的消耗 4. 功能影响，服务器处理每次的恳求的内容又多了 Session 服务器：同样可以是集群的。这种方式适用于 session 数量及 web 服务器数量大的情况 这种方案需要考虑的是： 1. 保证 session 服务器的可用性 2. 我们在写应用时需要做调整，我目前不晓得应用服务器能否将这部分规律透亮?????化 - 数据库读写分别 数据库的一部分读（未缓存、缓存过期）及全部的写操作都还需要经过数据库。当用户量达到肯定量，数据库将会成为瓶颈。这边我们使用数据库供应的热备功能，将全部的读操作引入 slave 服务器。留意：读写分别处理的是读压力大的问题。 由于数据库的读写分别了，所以，我们的应用程序也得做相应的变化。我们实现一个数据访问模块使上层写代码的人不晓得读写分别的