之前我一直不理解一个现象，很多领导开口必谈架构；这个现象充分展示了领导层对架构的重视，还有对架构师的重视。各个公司对架构师的定位也不尽相同，务实点的讲究基础扎实、经验丰富；贪心点的想让架构师解决产品、管理、开发、运维、测试、培训等所有问题。而程序员对架构师的认知也有很多差异，有的人认为架构师是公司里技术最牛逼的人，有的人认为架构师底层能力和抽象能力都得出类拔萃，还有人觉得架构师都虚头巴脑的，光知道ppt画些框框图，屁用没有，把代码写好才是根本。我觉得各种认知都有道理也都有失偏颇。
那么什么是架构，架构师又应该是什么样子呢？这一度困扰了我，并因此对自己的职业道路产生了怀疑。后来看到了个理论我非常认同，算是暂时解决了我的疑问。我们知道，无论什么系统，服务于业务才是根本使命。而架构师要解决的问题就是降低业务落地的复杂度。什么是业务落地的复杂度呢？就是在基于公司现状和成本控制的前提下，保证系统的高性能、高可用、易维护、可扩展等特性。当然，每个系统的主要复杂度，并不一定四个方面都有。而今天，我们就理论层面，白话一下其中核心的复杂度问题：高性能。虽然是讨论高性能，但不可避免的会涉及到高可用，这两个是相辅相成的。而高性能系统的考察指标一般是，吞吐量、响应时间、资源使用率这几个方面。
既然是白话，自然是想让人人都看得懂。而人人都看得懂的道理，也不一定是简单的，看看我是不是有深入简出的能力；其实，每个人都有架构师的潜力，哪怕不从事技术行业。
首先，我们知道，高性能是为了解决高并发和大数据量问题的。什么是高并发和大数据量呢？我们回忆一下双十一的场景，那就是典型的高并发大数据量场景。思考一下，双十一的那个凌晨都发生了些什么事儿。全中国几亿的网民，在非常短暂的时间内，购买了非常多的商品。而这个场景，对购物平台的系统造成了非常大的处理压力。压力体现在了计算机的资源层面，也就是计算、存储、网络。
解决问题的方法论都是统一的：先充分的认识问题，分析问题、找到瓶颈点，想办法解决。我们先从认识问题开始，分析场景，找到瓶颈点，然后慢慢的讨论一些可能的解决方案。
首先是“非常多的用户”，我们分析一下，这么多的用户，能不能从业务角度，降低用户量，或者说是筛选真实想发生交易的用户，剔除一些虚假用户？暂且不管降低用户量这个想法合不合理，其实很多稀缺资源的抢购，确实是需要剔除很多用户的，比如说抢购飞天茅台，抢口罩等等；具体的手段就有很多了，比如非常典型的预约制，就是提前预约的用户可以抢；还有现在互联网的做法，把双十一提前很早开始，让很多懒得抢的人，提前购买；这个层面其实很考验架构师的想象力，和对业务的理解能力。
好的，暂且认为我们对用户数已经做了能做的削减；我们接下来分析，在“短暂的时间内”这个点可不可以想点办法。大用户量和短时间其实是分子和分母的关系，双十一提前很早开始其实本质是通过时间来降低单位时间的用户量。业务角度上用户浏览和购买的行为是在短时间内同时进行的，而从系统处理的层面，我们一定要把处理时间控制在这么短的时间么？活干不完的时候，是不是可以先找个地方存着，在更多的时间内慢慢消化掉呢？这就需要系统有缓冲能力，而对于用户来说，对用户的一些行为就没法立马作出应答，而是提示正在处理，请稍后，这就是异步的概念。
第三个点是发起了海量的浏览和交易请求。仔细思考是浏览量大还是交易量大？应该是浏览量更大一点，你买之前也首先得打开商品的详情页面，怎么让页面顺利的被这么多用户打开，这个地方得思考一下；首先我们能想到的是网络的问题，也就是服务器的带宽够不够用。带宽是有限的，有限的带宽如何撑住更多的数据请求呢，我们很容易想到压缩机制和数据精简；另外怎么能让用户打开页面更快呢，我们很容易想到缓存机制，尤其是静态图片、内容等的缓存。
下一步就是要处理用户的交易请求了。这里为了更容易理解一点，我们用现实场景去举个例子。假设大白开了个蛋糕店，这个蛋糕店在上升期，大白也是个踏实肯干的人，什么事儿都亲力亲为。从招待客户、做蛋糕、收银都自己做。
因为生意非常好，大白一个人忙不过来，用户体验变得很差，买个蛋糕需要等一天。为了业务发展，大白把老婆叫来帮忙，老婆负责接待客户和收银，大白负责做蛋糕师，这个改变叫做分工，映射到系统内可以叫做分层，也可以说是服务拆分，也可以叫前后端分离。
大白的手艺实在是太好了，客户越来越多。这个时候发现老婆的工作压力不大，毕竟招呼客户和收银时间很短，很多时间都闲着，而大白太忙了，毕竟做蛋糕要麻烦太多了。怎么办呢，很简单，多雇几个蛋糕师吧。这个优化措施呢，思路叫并行，也就是一个人干不完，那就多个人干。而在系统层面的，叫做多线程。当然细节上还分多个人做一个蛋糕，和多个人做多个蛋糕；那这个措施有成本么，当然有，需要更大的厨房，从系统的角度上来讲，就是需要更多的cpu和内存资源。
假设大白生活经验太少，人比较傻。他开始的策略是来一个顾客就雇一个人，然后做完了给完钱就让蛋糕师走了。再来一个客户就再招一个人。这样的缺点非常明显，一个是招人这个行为本来就比较耗费时间，第二个是当客户比较多的时候，厨房放不下这么多蛋糕师。那怎么解决呢，就是稳定雇佣几个固定的蛋糕师，如果高峰期忙不过来再招几个临时工。这个就是池化的思想。连接池、线程池都是这么个工作原理，复用几个核心线程或者连接，设置最大线程数、连接数来防止把厨房撑爆了。
大白做蛋糕的工作压力缓解了，做蛋糕的效率直线增长。然而大白的老婆却忙不过来了。这时候有两个思路来解决问题，一个是再招人帮老婆分担压力（这个当然可以）。第二个是让客户先付钱，等蛋糕做好了再通知他来取。这个优化思路就是异步和缓冲，有了异步和缓冲，不但大白的老婆不那么忙了，连蛋糕师也跟着轻松了一些。当然不是所有的客户都能接受这种做法，他们还是选择等着。
大白的蛋糕在口口相传之下，生意更火爆了。而蛋糕店所有的人都非常辛苦。大白就思考，怎么能让大家不那么辛苦呢？大白发现，在中午和晚上的时候非常忙，而上午和下午都相对清闲一点；大白这时候想到了几个思路。第一个是在空闲时间对做蛋糕的原材料就行初加工，这个对应的思路是预处理和预热；第二个是对订单进行分类，如果客户不是急着要，完全可以安排在空闲时间做，这个对应的是任务调度、分流等；第三个是让客户使用电话或者小程序进行预订，并根据需要做完的时间安排具体制作的时间，这个叫预约机制；第四个，将仓库里的材料尽可能的搬到厨房里，节省去仓库拿材料的时间，这个叫缓存机制；第五个，把只看不买的客户和买蛋糕的客户分开招待（老婆招待只看不买的，招个新人负责买的），这个叫读写分离。
为了防止工人累坏了，更防止老婆累坏了，大白设置了保护机制。一旦订单存量和单位时间内的订单量超过一定数量时，就挂出提示牌，提示“一小时内订单已满，请一小时后再来”，这个对应的就是限流机制；之前不忙的时候，大白会给客户做一些小零食作为赠品，但是忙不过来的时候，大白就选择性的只送一部分客户，这个叫降级；当更忙了之后，干脆就都不送了，这个叫熔断。限流、降级、熔断都是为了保护系统，以免忙的崩溃了。毕竟赚钱和老婆，还是老婆重要一点。
然而过硬的产品质量，导致量客户量继续增加，整个城市的人都跑来买蛋糕；蛋糕店还是忙不过来，真是幸福的烦恼啊；当然这是对大白两口子幸福的烦恼，员工都苦逼的喊日了狗。大白想再招几个人，然而发现店铺虽然已经挺大了，但是人已经放不开了，怎么办呢？大白觉得，是时候开分店了，这个叫做集群，也叫做分布式改造。和一个人干不完多个人干一样的思路，一个店忙不过来，就多开几个分店。
然而开分店没有那么简单，管理问题、协同问题都日益凸显。这些就是分布式领域的可用性、一致性、分区容错性的问题。首先要解决的问题是客户分流问题，就是要把总店的客流分散到各个分店去，这个叫做负载均衡；而有些分店可能出现停电问题，某些天不开业，得提醒客户当天不要去，这个叫高可用。
其中有个比较具体的问题，以前在总店办会员卡的人，到分店还要可以用。这个叫状态保持，或者是session共享。当然还有些别的问题，比如分布式锁、分布式事务、服务治理等问题。
到现在，一个城市的客户已经能满足了，满足其他城市的客户又成了需求，而且万一一个城市的店铺都停电了，还有其他地方可以买到蛋糕；这个叫做两地三中心多机房部署。多中心多机房又带来了新的负载均衡和网络路由问题。你想想，自己的城市就有蛋糕店，非得跑别的城市买，效率得多低。而dns就是为了解决这类问题。
后来，大白发现，接待客户、收银、制作蛋糕等等职责还是可以细分，于是系统分为了展示层、负载均衡层、网关层、服务层、存储层、基础设施层等
再后来，大白发现制作蛋糕的过程也需要再细分职责，于是系统走向了微服务，而微服务框架提供了网关、注册中心、配置中心、运维监控等。
最后，大白发现，开分店和管理分店的过程很频繁而且很麻烦，于是使用Jenkins、k8s、docker等技术来实现持续集成、持续部署、持续交付；还有采用了服务网格等微服务的进阶版本。
当然，在运营这么多分店的过程中，对店铺本身的资源和基础设施的掌控也尤为关键。于是对cpu、内存、硬盘、网络的监控和运维能力也成了必备技能，其中需要使用哪些指令和关注指标也是重中之重。对应的测试和监控体系也需要搭建起来。
到此为止，通过大白的蛋糕店的发展历程，我们走过了系统高性能优化的所有步骤；你看，蛋糕店人人可以开，架构师人人可以做。不过话又说回来，蛋糕店不是谁都能开好，架构师也不是谁都能干好。从来没有因为生意太好而失业的蛋糕店老板，而有好多因为生意太好而失业的架构师。另外很多思想和做法没办法用一个蛋糕店的故事来完全讲完，比如是推还是拉，算法优化，系统调用等等，不过道理都是相通的。
怎么样？程序员和架构师一点都不神秘，一起来做架构师吧。
网友评论