下面我来看一下架构实战以及遇到的问题
1. 企业后端架构挑战
1.1 问题总览
企业架构挑战主要是两个部分： 第一部分是基础设施层面，物理资源是有限的，无论是机器资源，CPU，存储都是有限的，其次运营商给予带宽也是有限的。并且往往资源利用率还要受制于不同的部署方式的影响。
第二部分用户层面，网络开销可能比较大，网络抖动导致的运维成本提升，不同的物理机器的指标并不好判断，比如苹果M1芯片的60%CPU使用率和Intel的60%CPU使用率是两种不同的情况。
1.2 离线在线资源池
在实际业务开发过程中，很多业务根据属性会被分成离线业务和在线业务。通常来说在线业务一般是IO密集型，对于读写的消耗很大。并且在线业务往往伴随着潮汐性，有着高峰和低谷，一般早上8点，晚上6点都是高峰，对于业务的压力很大。而凌晨相关时间段业务的请求量又会很低。并且在线业务有着很强的实时性，可能出现了一个热点新闻，大家都来看爆满。过几天这个新闻过去了，新闻无人问津。
相比而言，离线业务大多以计算密集型占多数，并非实时性的业务。很多时候离线业务用也行，不用也行。如果服务器压力很大完全可以暂时先降级不使用，一个短视频APP就算推荐系统挂了，也比APP本身挂掉要划算。
针对离线和在线资源的特点，提出了离线在线资源并池，统一管理离线和在线资源。首先这样可以降低物理资源的成本，使用率提高了。并且可以提供更多弹性资源，提高收入。比如我们可以在在线业务低谷期的时候，将部分资源用来提供给离线业务部分使用，极大提升了资源利用率。
离线资源和在线资源并池可以通过资源容器化来进行，下面是并池的一个示意图。
1.3 自动缩容扩容
其次根据上面我们提到的在线业务的潮汐性的特点，提出了自动缩容扩容。一旦我们业务访问量激增，我们自动提高服务器的相关配置，防止业务被击穿。一旦访问量持续下滑，自动降低服务器相关配置，防止资源的浪费。
下面这是自动缩容扩容的示意图：
1.4 微服务亲和性部署
微服务亲和性部署指的是将具有较强关联性的微服务打包在一起，部署到同一台服务器上。通过微服务的亲和性部署可以使微服务中间件与服务网格通过共享内存通信，同时服务网格控制面实施灵活、动态的流量调度，来最终达到降低业务成本，提高服务可用性的目的。
下面是微服务亲和性部署的示意图：
1.5 流量治理
随着业务的增多，流量治理也成为了难题，为了提高·提高微服务调用容错性，更好的容灾 以及进一步提高开发效率，DevOps发挥到极致，提出了基于微服务中间件&服务网格的流量治理。其主要手段有 熔断，一旦某个服务发生了故障并且多次重试，立即进行将这个服务进行熔断，虽然这个服务暂时不能使用，但是整体服务还是可以使用的。
上面讲到的重试也是我们流量治理的重要手段，有时候可能只是网络波动并非业务问题，只需要多试几次就可以了。最后就是复杂环境单元的流量调度。
1.6 CPU 水位负载均衡
下面是一个CPU水位负载均衡的示意图：
其主要就是解决我们上面的异构环境下资源环境差异的问题，同时也可以对于我们什么时候自动缩容，什么时候自动扩容给予一个好的参考。
其解决思路通过Service Mesh来利用Iaas的提供的资源探针进行CPU的水位进行一个负载均衡的统一调度。有关Iaas介绍可以看上一篇文章的介绍架构初探谁动了我的蛋糕 学习笔记 ｜ 青训营
2. 后端架构实战
2.1 问题提炼
首先我们来看一下我们需要达到一个什么样的效果：
- 紧急回滚能力
- 大规模
- 极端场景下保持可用性。
接着我们看一下我们拥有的东西：
- 服务网格数据面 和支持带权重的负载均衡策略
- 注册中心存储了所有容器的权重信息
- 宿主机能提供容器的资源使用情况和物理资源信息
整个系统的架构图如下所示：
2.2 自适应权重
首先我们设计成为这样的自适应静态架构：
采取的方案是采集宿主机物理资源信息来调整容器注册的权重。 优点复杂度低，系统完全分布式，可用性高， 并且微服务中间件无适配成本。 但是缺点显而易见：无紧急回滚能力且缺乏运行时自适应能力。
2.3自适应动态权重
针对上面的问题，我们对其进行改进，提出了动态自适应权重。
其方案是通过容器动态权重的自适应调整以及充分利用服务网格的服务发现和流量调
度能力。
优点：解决无法紧急回滚的问题并且运行时权重自适应。
缺点：过度流量倾斜可能会有异常情况，极端场景的处理没有办法
2.4自适应动态权重改进版本
针对极端场景，我们继续进行改进提出了改进版本。
我们使用服务网格上报RPC指标，通过时序数据库将其进行存储，这样一旦极端场景出现
RPC的时序指标可以提前发现。
但是也有缺点时序数据库压力太大存储内容太多，动态决策中心的功能太多了，不好进行优化升级。
2.5 自适应动态权重微服务
将动态决策中心进行了微服务架构挑战，使用一致性哈希解决在线分析弓引擎的数据一致性问题。为了解决解决时序数据库压力：将其作为旁路工具，采用纯内存的在线分析引擎进行实时策略计算。
针对离线分析：使用消息队列解耦、削峰，使用离线回馈在线。
3. 总结
我们应该如何做架构设计？
- 需求先行。弄清楚要解决什么问题，需求分析永远很重要
- 业界调研。业界都有哪些解决方案可供参考，各种轮子
- 技术选型。内部/社区都有哪些基础组件
- 异常情况。考虑清楚各种组件不行了怎么办，各种极端环境出现我们应该怎么应对。
本文主要介绍了架构过程遇到的挑战，以及架构实战过程中遇到的一些问题以及一步步如何演进发展的，希望可以对您有所帮助。
