这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
在搭建运用企业级的后端架构时，会有很多的问题出现。下面列出一些主要挑战。
挑战
基础设施层面：
- 物理资源是有限的：机器和带宽都是有限的。
- 资源利用率受限于部署服务：有时候在机器上部署服务，可能虚拟化程度不那么好，或者是占用了这个资源但是利用率较低，很多的资源都在buffer中等待。
用户层面：
- 网络通信开销较大，不像本地部署的直接调用就行了，不同微服务之间需要通过网络进行调用。
- 网络抖动会导致运维成本较高。
- 异构环境下，不同实例资源水位不同。
离线在线资源并池
开发企业架构主要是为了售卖相关的云服务来获得收益，那么我们需要考虑的一个重点就是如何降低物理资源成本，提供更多的弹性资源。那么就需要引入离在线资源并池。
由于总的资源还是只有那么多，因此我们需要根据离线任务和在线任务的特点来分配二者的资源量。如上图就是根据在线任务的潮汐性和实时性来分配在线资源池和离线资源池。
在线资源特点：
- IO密集型（在线资源一般都会有高并发的输入输出）
- 潮汐性、实时性。（如在凌晨访问量很少，晚高峰访问量很大。实时性指像用户在进行榜单刷新时必须很快提供给用户而不能等个几分钟啊啥的。）
离线任务特点：
- 计算密集型占大多数。
- 非实时性。
那么需要根据什么指标来让系统进行在线和离线资源的扩缩容呢？可以根据cpu使用率或者有些任务根据内存使用率。目前的技术很难将IO作为指标来衡量。
微服务亲和性部署
在云服务架构中，网络传输也是一个损耗，为了更好的减小成本，会将亲和性较高的一些微服务部署在一台主机上，让其进行共享内存通信或是其他的主机内的通信
流量治理
由于是通过网路连接，我们需要提高微服务调用的容错性。需要容灾并进一步提高开发效率，将DevOps发挥到极致。
解决办法： 基于微服务中间件和服务网格的流量治理。如单元化、复杂环境的流量调度。
cpu水位负载均衡
前面提过在异构环境下会出现算力差异，为了解决这个问题同时可以为自动扩缩容提供正确的输入。我们需要进行cpu水位负载均衡。
- Iaas层面：资源探针
- 服务网格层面：动态负载均衡。
