架构的演进

序言

小孩子最好的地方在于，无论你对他怎么样，他一直对你还是怎么样，前一秒在哭，下一秒就会笑容满面，而成年人不同，别人的一句话，可能就是一把刀插进心脏，久久不能恢复。

小孩子只是一个缩影，那么问题来了，在什么样的阶段，我们丢掉了这种最最优秀，最最重要的品质，无论你对我怎样，我对你依旧一如既往。

风言风语

1 架构的演进

在最早进行写程序的时候，都是单体应用程序，所谓的单体，就是一堆人写一个代码库，服务器也就是一个应用，一个数据库。

单体架构带来的最大的问题，就是运维的问题，这个时候，都是单点状态，那么只要一个挂了，就整体不可用；另外一个问题就是当流量上升的时候，会导致性能降低。

在解决以上的两个问题的时候，就进化出了高可用架构，也就是使用负载均衡和集群的服务，应用变成多份，数据库也变成了高可用的架构。

高可用架构的出现解决了单点问题，也解决了当容量性能不足的情况下，进行快速的扩容缩容的操作，但是随着业务的发展，人员组织架构的扩大，几十号人公用一个代码库，开发效率出现问题，各种上线的时候都需要大量的人力，从而出现了微服务架构。

微服务架构通过各种方法将单体架构的代码进行拆分为小的服务，从而每个小服务由专人来进行负责开发，升级，维护，从而大大的提高了研发效率，但是带来的问题也是很大的，有拆分的方法论，拆的好的提高研发效率，拆的不好的搞死开发，测试，运维，运营，最后业务变得更加复杂，部署也带来很大的复杂度，各种版本之间的维护与交互，运维就更复杂了，故障处理，服务治理，如果没有链路跟踪，原来的一台服务器查看所有日志，现在呢，可能一百台，而且这个还涉及到成本，如果单体只要一台服务器，那么微服务的服务器数量是翻倍的。

云计算的出现并没有解决前半段的问题，只是解决了后半段的问题，也就是解决了部分运维问题，解决了发布部署的问题，解决了服务治理，链路跟踪的问题，当然，你要选择合适的云，并且要选择合适的开发框架。

在选择云计算的时候，需要进行规划，选择合适的云产品，才能更好的促进业务的发展，从而将很多底层的运维工作给去掉，就像原来的IDC里面的IAAS的运维，在IDC里面自建的PAAS运维。但是你会发现当上了云之后，很多人是采取平行迁移的方式，从而导致和在IDC环境没啥太大的区别，依旧很复杂，上云之后，第一件事做的就是重构优化，从而将应用改造成适合云的架构，那么就引入了一种新的架构，那就是云原生。

云原生不是一门技术，而只是一种概念，第一个必须是基于云产品的架构，也就是你已经没有自建的各种东西了，都是使用云厂商的产品，原来你的日志收集是ELK，那么现在你就是用日志的产品了，原来你的数据库是自建mysql主备，那么你现在用的就是各种RDS了，总之，只要是IAAS和PAAS的东西，你全部买买买就好了，你要不是买，那就不是云原生的，因为你要为云而生，cloud native；第二个就是使用微服务+k8s，用了微服务，那么就必然会用到容器，用到了容器，那么要进行智能调度，就需要k8s来进行管理应用的生命周期了。

云原生到底解决了什么问题呢？云原生解决了智能扩缩容的问题，也就是根据业务的流量来进行智能的变化，当业务流量上来时，自动增加pod来进行负载均衡，当业务流量下来之后，自动减少pod来减少成本。也让故障自愈变成可能，当应用OOM了，会自动删除坏了的POD，然后会新起一个好的，从而做到故障自愈，再也不用担心运维了。

serverless要来了，那么devless还会远吗？

2 判断力

我们总说判断力，所谓的商业sense，所谓的运维sense，这是一种感觉，从不断的判断中去提高相关的能力。

最近发现，感觉比较好的，都没成，相反感觉比较差的，都要成了，这也是见了鬼了，那么问题来了，到底是哪个环节出了错，骗过了自己呢，这是一个很有意思的问题。

看别人写的PPT，那才是PPT，看看自己写的PPT，那都是一坨屎。。。PPT写多了，去掉那些所谓的样式，看看里面的内容，你就会发现真正的差距并不是PPT，而是在各种知识的杂糅，几句话，几个图，表明心迹。。。

不怕表面产生的差距，就怕内涵的差距，因为这种差距需要巨大的时间和努力去弥补。

所谓的竟业协议，其实更像是离婚协议，你不能去找你老婆的闺蜜结婚，因为这样都没脸见人了，换老婆有成本，而换工作也有成本，该来的总是会来的。