架构师_01-架构师的道 _架构

归志宁无五亩园，读书本意在元元。这篇文章主要讲述架构师_01-架构师的道相关的知识，希望能为你提供帮助。
以道驭术，术必成。离道之术，术必衰。--庄子
术指的是具体做事的方法，例如采取什么设计方法，哪种语言去开发。好的方法可以让你用最短的时间达到最大的效益。而道是自然规律，是做事遵循的原则方针。术必须建立在正确的道上。这几十年互联网的蓬勃发展，各种各样的软件为生活服务，从事开发行业的新生代宝宝也时常感到焦虑。本文主要是结合一些实践经历，浅谈一下架构师的道，希望能对刚入行，或者已经从事软件相关行业开发的同学有所帮助：术有千变万化的，而掌握正确的道则可以以不变应万变，面对变化如庖丁解牛般操作自如。
先说下背景：工作了十余年，虽然没有太大的建树，但也一直奋斗一线，参与过N个系统的设计和落地，每年起一些新的小项目进行实践。最近听了NX的视频课程，感觉收益颇多，整体内容都是基于实战的高度总结，和我在微博工作的这几年碰到的case很相似。几乎所有的内容，我都直接或者间接接触到了。现在静下心总结一下吧：
一个案例

这是我刚来北京的时候的一个案例：当时我们所在的公司和竞争对手的公司同做一款SNS游戏，我们底层数据库采用区间算法的分表分库方案，为了缓解压力，在读多写少的情况下，我们采用memcache进行缓存，同时为了缓解写带来的数据库的压力，我们的系统采用异步的架构模式。即：每次的请求没有直接写到数据库，而是写到了缓存里，然后再由独立的应用程序定时写到数据库。当用户量暴增的时候，可以通过复制从库，分配区间的方式快速扩容。这个架构保证了我们的游戏短期迅速的拿下了市场。而竞争对手因为无法面对忽然涌入的流量，而导致服务瘫痪，浪费了时间从而导致业务失败。
以上的架构也在我之后接触的系统中或多或少有所体现，例如：一个系统经过几年的发展无法扩容了，DBA更是要求接手的开发人员处理，而因为固定了架构，无法在满足业务的情况下，快速扩容，看着系统走向死亡。还有一些明明理论可行的方案，实施起来却漏洞百出，时间上无法保障，质量上不过关，天天修补漏洞。开发宝宝心里苦，而产品又总投诉开发不给力。为什么会这样呢，我想还是因为缺少一种架构思维吧～

文章图片

工程师、高级工程师和架构师
对这三个角色，我是这样认为的：
刚入行从事软件相关的开发工作，做的很慢，需要熟悉的阶段属于初级工程师。这个阶段需要高级工程来带，旨在熟悉业务，能够实现一些简单的功能。至于高级工程师，当初级工程师打怪的经验越来越丰富的时候，此时不是要高级工程师带领，就能够很好的和产品交流，基于现有的架构模式去实现功能，属于这个阶段。而架构师，更关注架构和未来，我的理解和高级工程师之间的界限不是那么明显，一些所谓的架构师，落地某些方案甚至不如高级工程师的优雅。总之，你能够根据你所从事的工作范围内容，给出低成本高输出，适宜的解决方案，你就是这个工作领域的架构师。

文章图片

架构师的职责
1.业务需求分析
一切脱离业务的架构都是Some Body(SB)架构师。架构师应该能分析需求背后的真实需求，举个例子: 你想买辆汽车，因为上班总迟到，自己开车方便点儿。但是北京的摇号是那么的痛苦，那么你的真实需求就是买辆汽车么？其实不是，你还有其他方案：比如买个电动自行车，上班不堵车还方便。或者，找一下其他的路线，每天坐顺风车拼车上下班，最后总能找到一个适合的方案去实现你的目标，这些都与需求背后的真实需求有关。工作越久你会感觉到解决问题的方案不仅仅是一个，引入新的架构是一个方案，而针对现有的架构做升级又是一个方案，权衡利弊的依据是找到你现在的真实需求。

文章图片

2. 架构的设计
为了突出能力而选择不适宜的架构，是灾难性的，。一个简单的单体架构非要进行拆包，思想是没有问题，但时间和人力及运维的维护成本巨大。是微服务架构还是ServiceMesh架构，是同步的架构还是异步的架构，无疑是需要根据一定的规则设计的。

文章图片

3. 架构的选型
首先确定你要用什么架构模式，是微服务架构还是单体架构，是同步架构还是异步架构，虽然互联网公司，但也要根据实际情况选择服务的架构。其次是架构的落地，比如微服务架构：是选择dubbo，还是用spring boot还是grpc的框架。还是其他框架。有人觉得spring boot框架成熟就用它么，当然不是，如果你的公司没有人知道这块儿技术栈，那么无疑dubbo相对来说好一些。
不是为了选架构而选架构。

4. 容量的规划
关于容量的规划，既要适度超前，也不要过度设计。本来4个redis或者8个redis能够解决的问题，非要搞出五六十个，美其名曰不用扩容，但这个设计确实不算优雅，运维维护的成本相对较高。
一般设计容量规划是六个月到两年，这是根据互联网产品的生命周期而定，但我想说，根据业务场景而定，我曾经做个一个配置模块，目前用到了第6年，而且中间没有出过问题，现在还在高频使用。考虑到规模大，难以维护，我这里根据业务类型在前几天进行了拆分，这个设计方案在业务模式不变的情况下，用上10年是没有问题的。

5. 代码的落地
架构设计的再好，代码不落地或者落地的不优雅，只能成为不值钱的PPT架构师或者让别人吐槽的架构师。例如：把一些效率不高的函数，用于高频使用的场景。用众人不熟悉的设计模式设计方法，根据产品逻辑写出的代码不能还原成业务逻辑，业务代码读起来像天书。

文章图片

业务代码的目标主要是满足这四个方面：

满足老板或者领导的战略需要，组织人把事情干成了。
实现了功能，满足产品的需求目标，让用户看到期望的功能。
自我价值的体现，什么能证明你创造了价值呢，用代码实现了功能。
接盘的同事，前期代码质量的好坏直接关系后期接盘同事的路是平坦还是曲折，预留了扩展，后面的同事能够很方便的熟悉业务扩展内容，如果没有，那只能美其名曰给后面的同事创造了填坑的“机会”。

什么是好的业务代码呢？我这里有个原则：简单适用为主要原则，另外需要关注新人的学习成本。毕竟是业务代码，不是越浓缩越好，我的第一原则是“简单”，·不仅要实现基础业务的功能，更要写简单的代码，简单的业务逻辑要能还原流程图。很多工程师，没有考虑清楚就匆匆代码落地，然后花去大量的时间去修bug。我想这是代码的落地能力问题。

6. 架构的服务治理
架构治理实际上是运维体系的范畴，例如微服务注册发现，服务的降级熔断，ab测试，灰度发布能内容，现在互联网的应用动不动就几千台应用，怎么有效的扩所容，保证资源的最大有效利用率。这都是值得我们研究的问题。上云带来了什么，是使用自采服务器还是上云，容器化等等的，都是一种能力。一个有经验的老司机不仅仅要关心代码层，更要关注运维层。

CAP架构模型
什么是CAP？现在的网站大多数是分布式的，而分布式最大的难点是各个节点如何同步，而CAP非常详细的诠释了这个问题。

文章图片

一致性（Consistency）、可用性（Availability）、分区容错性（Patition tolerance）,CAP原则是指，这三个方面最多只能满足两个，而无法三者兼顾。
分布式系统中要么满足AP，要么CP，而AC的系统很少见。一般不做考虑。
现在重点说下AP和CP的区别，主要区别还是CP要求强一致性，而牺牲可用性，例如 etcd。而AP模型更加关注的是可用性，而允许一致性的缺失，如主从服务的redis。以上是网上的基本介绍，大同小异吧。
我这里要说的是要认清你的系统是AP模型还是CP模型，是牺牲一致性保证可用性，还是必须保证高一致性。如果是AP模型，那么就要保证可用，社交领域的应用，大多数是AP模型，有时候会通过缓存异步等方式达到最终可用。当然在整个过程中是可用优先的。而CP模型的案例，比如etcd，始终保证一致性，在选举的过程中是牺牲可用状态的，当然这并不是说不需要关注AP的方面。
我们从事的社交领域行业大部分是AP的模型，而一些金融保险电子商务等领域相对来说更看重是CP模型吧。比如一条微博发不出去，或者数据错误是可以容忍的。而一条合同或者一个订单没有是有可能引起灾难性后果的。

BASE架构模型
BASE理论是CAP理论的CAP理论的延伸，核心思想是在无法做到强一致性的情况下，采用合适的方式允许中间状体最终达到一致性。我这里简单介绍下：

基本可用（Basically Available），指的是分布式系统在出现故障的时候，可以损失部分可用性，来保证核心功能可用。比如：微博在应对突发流量的时候，通过降级，熔断，保核心服务核心接口等，这些都是损失部分可用性的体现。
软状态（Soft State），指系统存在中间态，在同一时间节点，系统存在中间状态，而这个状态不影响系统整体的可用性。Redis主从同步会有不同节点间的延迟，如果这个延迟不影响使用，可以被允许，那么这个就是中间状态。
最终一致性（Eventurlly Consitence）是指系统经过一段时间后，通过一定的操作后，最终达到各个节点间数据状态的一致性。如 Zoopkeeper的Zab协议，Etcd使用的Raft协议等。

举个案例：我们的业务配置发布系统，从操作人员点击发布，到配置同步上线生效中间有10分钟左右的时候，这10分钟的时间受系统环境等诸多因素的制约，在业务使用的时候也和产品说好，达成一致，大家表示接受，我想这个状态应该是最终生效前的中间状态。

本文主要介绍了架构师的职责和CAP理论，BASE理论的内容，还是如开头说的那样，术有千变万化的，道是不变的，拥有一套成体系的思想，找到属于你的道。可以帮助你披荆斩棘，从容的应对一切困难。加油！
【架构师_01-架构师的道】共勉～