架构优化与依赖管理-优快云博客

本文链接：https://blog.youkuaiyun.com/how_interesting/article/details/80023879

对于架构优化的一些思考

纯属意淫，如有雷同，倍感荣耀

优化与过度优化
弱依赖，强依赖与过度依赖
整体与部分

优化与过度优化

性能优化，是指性能出现问题，流量出现瓶颈才进行的优化，不要出现优化而优化

过度优化，这个词可能出现在SEO里面比较多一些，但是在实际行为中，这种情况也是比较常见的

    public String test(@RequestParam("a") int a){
        long numberCount = getNumber();
        handleXXX(numberCount, numberCount, numberCount);
        return new String().concat(handleXXX(numberCount, numberCount));

    }

例如上面的代码中，为了节省计算时间，把一个计算结果保存为一个局部变量并在后面调用中，进行多次调用，实际上，计算机的运行速度比你想象的快得多，如果这种调用会产生大量的局部变量，如果不是计算严重影响时间（例如mapreduce）之类，其实都可以在底层函数中再调用一次。。。

也有很多为了节约查询数据库时间喜欢把类数据缓存在局部变量中，其实这些都是比较快操作，如果性能上出现问题再考虑用redis或者guava做本地缓存。。。。

推荐阅读《重构改善既有代码的设计》（虽然是老东西了，但是里面的对库类设计，函数设计值得参考）和阿里java编程规范（p3c插件了解一下？）后期我会整理关于这本书的读书笔记，但愿两个月内有时间搞出来，阿西吧。。

弱依赖，强依赖与过度依赖

其实参数需不需要校验，校验到什么程度，是不是需要底层依赖去解决上层业务？？这些都是很有意思的问题。。。（装逼是一件很有意义的事情）

弱依赖

有些类似java的弱引用，很容易消失，就是被内存回收也没关系，弱依赖也是，你依赖的包，或者报错，都不影响功能。

场景1：A调用B，A的主流程不需要等待B的返回结果

浏览器弱依赖：A从浏览器上发起异步请求，如果B挂了，那么只会出现页面某一个区域不显示B的内容，如果对于用户交互可以接受，那么系统层面无任何问题，商品详情页面的评论列表和购买记录就是这个情况异步线程：A调用B的时候只发送消息，然后调用动作由另外的线程来执行，并且不需要即时反馈结果，一般作为消息通知，轨迹记录等场景使用。不过为了防止堆积，也需要控制队列的大小

场景2：A调用B，A的主流程需要等待B的返回结果

设置超时时间：如果B响应超时，则抛出超时异常，绝对大部分情况下OK；不过两种影响要考虑：1、超时时间设置过长或者过短导致的副作用 2、大量异常抛出设置最大并发请求数阀值，一旦超过阀值就跳过访问B 两种方式相结合使用最佳。

强依赖

A系统依赖B系统资源，当B系统发生故障的时候，A系统势必会被拖累，导致A系统也发生故障。这里的依赖要区分两种情况：

1、A强依赖于B 任何强依赖都要尽可能的转化成弱依赖，因为强依赖本身意味着一荣俱荣，一损俱损.

对于强依赖B这个场景，从稳定性来说我们还是可以做一些事情：
当B发生故障，虽然A系统不能正常执行业务，但是A不能挂掉，一旦B系统恢复，A系统也要做到立即恢复。同时A有责任对B要进行流量保护，而不是对B进行摧残。如果系统没有做特殊的保护，当分流的量大于了单机的容量，持续一段时间后，系统将不能很好的恢复，即便我们把分流进入的量减少到系统容量以下也不能快速恢复。

过度依赖

依赖底层报错，或者底层逻辑去解决上层业务问题

1.数据库唯一索引

很多人写代码为保证业务唯一性，都会使用唯一索引去解决，但是你每次增加数据，都完全依靠数据库报错（1062 Duplicate entry ” for key）去判断业务的正确

2.函数参数校验（RPC？？）

参数应该校验不，如果不校验直接去try catch 去捕获底层报错，然后判断业务正确？？

有向无环图

一个好的架构，应该如何拆，拆到什么程度才是好的？？

有向无欢图

avatar

一个好的架构内部应该是一个有向无环图，所有依赖都指向底层基础服务，而不会出现环形结构（论环形结构的不稳定性，三角结构，只要一个脚挂了，就应该雪崩了），如果出现环状结构，大部分情况就是服务没有拆干净。。。

整体与部分（高可用？？）

如何划分高可用。。

这个应该划到有向无环图里面来讲的

高可用应该做到什么程度？？

最简单的数据库高可用，应该数据库对外提供的是单一的简单的服务（关系结构数据的存储），缓存高可用也是对外提供单一的服务，同样的，我们在设计结构层次时，高可用的对象也应该尽量提供单一的高可用，去降低全局影响，例如RPC服务，每个对外服务尽量单一，这样也比较容易做容错，不然你也就只能做整体的高可用，这样还是会出现整体的某部分出现异常的问题