10 | 架构设计流程：识别复杂度

文中有一句话：TPS 1780 并不高。这个结论怎么来的？作者经验丰富，见过很高的TPS。 但作为新手，如何衡量这个性能要求高还是不高呢？

感觉这个专栏定位是扫盲，留言的读者都是老司机

复杂度问题，还有是方案简单，但是沟通协调成本高，跨部门了，请问华仔，你们是自己推动，还是技术PMO推动。

说下之前改造的一个系统，当时是这个系统从其他系统同步数据，经过一整套流程后将数据拆解到本地库的各个业务表中。 原来的系统是一个单机多线程程序，到了大促的时候延时非常厉害，因为马上又要大促了，首先想到的是扩展性的问题，于是就做了无状态服务拆分，可以横向扩展。在这过程成因为要控制单个同步实体任务的并发在处理幂等性上也花很大的功夫。做完这个后，又对非关键流程做了消息解耦，提高主流程的处理速度。 系统上线后运行稳定，但是到了大促当日发现速度提升很有限，将机器扩展到10台速度只提升了2-3倍，而且数据库和应用压力都很小。 后来分析下来瓶颈竟然是在数据库中间件上。其他系统大量的慢sql导致中间件处排队严重。 现在想起来，其实还是改造前优先级没搞清楚，根据之前的经验就把问题归结到扩展性上，投入了大部分精力在扩展性和可用性上，而没有对原来单机系统的性能做完整的测试和评估。其实当时做一个单机程序的压测大概就可以判断出问题所在(改造过程中也发现老的程序确实有bug)。还有就是高性能的优先级远大于扩展性和可用性，因为这个系统重启的影响非常小。改造的时候过于理想化的，想做一个各个方面均衡完善的架构

最近在做一个平台化的crm系统，也就是公司各个业务线都可以接入 ，或者外面的业务线也能接入。但是我们在开发过程中，比如查看商家等级列表这个接口，以前所有的接入方，都是查看就是查看，但是有个主要对接方提出了个需求是，查看后如果不存在 就插入一个默认等级。，但是其他对接方没有这样的需求，也就说原接口不能变，如果没有其他接入方我直接修改原来的接口即可，根本不考虑兼容。类似的问题数不胜数， 我们每次要么是if else这种代码走不同的逻辑，要么是 新写个接口，现在我们的代码的维护已经很混乱了，一个简单的逻辑，如查看等级列表，我就要维护好几套接口，好几套逻辑。 有想过变成可配置化的，但是没有好的思路。华哥对这方面有好的建议吗？😂

微服务架构，是解决了什么复杂性问题呢

公司架构日志占了百分之二十的cpu，有什么好的解决方案吗

我现在做的是交易转发网关，性能瓶颈很大一部分也受上级券商网关影响，系统无状态，无数据库操作，因为涉及到交易，对可用性要求很高，需要能快速处理客户端的请求，经过多次压测，也没有排查出自身系统问题出在哪里，对系统压测，以及测试得到的数据该怎么分析，怎么找出问题所在？

识别复杂度方面比较难，如果判断错误，容易误入歧途。像我们公司是属于创业型公司，业务迭代很快，前面两三年都在堆业务，并且所有的业务都在一个系统上，web服务器一台，数据库RDS一台，那个时候流量并不大，公司高层没有重视，不考虑优化，还是以发展业务为主。 今年业务量起来了之后才重视，流量会对现有系统有所影响。于是讨论出最终方案，重新起一套框架，来重构，原来的老系统继续使用。结果实施发现周期重新起一套开发时间上，公司等不及，开发了3个月都没有出来就胎死腹中了。 但那个时候开始老系统经常频繁出问题了，有时是web请求量比较大WEB服务器CPU 100%，WEB服务器都登录不进去。有时是数据库操作比较频繁，数据库100%。只能重启web服务器来临时应对，有一次业务高峰更尴尬，连服务器重启都没有用，一重启流量一进来又100%。 这个时候通过分析web请求日志，慢查询日志来进行分析，然后来制定出优化方案，在原有的老系统上来进行优化。 但推进这个优化的过程中，也是比较费劲，研发人员比较害怕在老的系统上来进行优化了，怕优化后用不了，这好比是在给飞行中的飞机加油。后面通过领导的支持下达，通过分析报告的结果，把老系统的服务由简单到难逐步拆分： 1. 先拆分的是静态资源放到OSS上并做成CDN化。 2. 将慢查询进行优化，能利用缓存的，用缓存，大表的联表查询，拆分成单表查询。 3. 将轮询在调用接口的迁移到其他服务器，将一些轮询的计划任务服务也迁移到其他服务器。 这样子系统算是稳定下来，但要走的路还很长。 我写了这些事故的经历，就是在互联网公司成长过程中都会经历，对于技术复杂度的判断很重要，要是一开始我们就打算先从老系统来进行优化，就会避免一些事故的发生，还有就是技术上的推动，还是需要由公司领导的大力支持，首先要说服领导，说服老板，上通下达才行。

做了一个很小的系统，就给几个领导看，所以写代码的时候，没注意加锁，和并发。所有的功能都在一个系统里，只求速度。。。