闲聊架构

序言

架构本身就是一个伪命题,因为很多东西的考虑是一种权衡,也是一种选择,并且含有各种约束条件。

架构可以从各个角度来看,可以从业务,从而有业务架构;可以从开发角度,从而有逻辑架构,有开发架构;可以从运维角度看,从而有部署架构。

架构

无论你想与不想,其实架构就在娜里。

写程序的时候,你会涉及到各种业务系统的架构,系统之间的拆分,一个大而统的系统拆分为各个子系统,子系统中又划分为各种组件,在开发的时候,又可以在各种框架中进行开发。

而架构又能解决什么样的问题?架构主要是根据需求,识别其中复杂的地方,从而对这个复杂的地方进行设计。

架构应该追求什么?在各种架构中,都追求高性能,高扩展,高可用,高可靠,安全度高,成本低。看看nginx的说明,高性能,每秒处理的连接数几万次;看看分布式存储,高可靠;看看金融领域,高可用,安全;看看云平台,高扩展。

每个产品或者组件追求的方向不同,从而导致设计的结果完全不同,例如都是分布式存储,GFS追求用极致的性能来存储大文件,从而将元数据保存在内存中;TFS追求用来存储大量的小文件,从而将元数据保存在数据库中;我可以在软件层面高可靠,从而有了分布式,我可以在硬件层面高可靠,我可以做RAID。

每个产品或者组件追求的方向相同,设计的人不同,也会导致结果完全不相同,例如nginx追求高并发,可以使用多进程也可以使用多线程;redis也实现了高并发,但是使用的是单进程;jboss为了实现高并发,使用的多线程,采用的技术不同,但是导致的结果都是相同的。

为什么追求的目标相同,但是实现的方式不一样,为什么不采用同样的标准???

你能说出上图中几种架构的好坏么?哪种更好?哪种性能更高?哪种可靠性更强?哪种安全性更好?哪种可靠性更好?哪种能更好的适应业务的发展?

其实架构不分好坏,都是带着镣铐跳舞,在各种约束的条件下创造出最合适的架构。。。

约束?有哪些约束。。。团队只有三个人,都是新手,能做出各种高性能的系统么?团队从来没用过Jboss,能做出稳定的系统么?团队没人会使用分布式存储,能使用这种重量级的产品么?

团队约束。。。只有这么多人,只有这么多的经验。

资源约束。。。我要上各种高可用高可靠的组建,我要使用GFS,有人会用么?有人会维护么?

时间约束。。。我要划分成100个子系统,做成微服务架构,有那么多时间来划分各种接口,开发,测试,部署,运维么?

成本约束。。。我要部署成高可用的架构,我nginx要用两台负载均衡,会话保持,我jboss要做成集群的模式,我mysql要主备复制。。。有那么多的服务器么?

合适才是最好的,如何在有限的条件下做出稳定的系统?这才是主要要考虑的问题。。。其实合适也不好说,可能在当前的情况下是合适的,但是过一段时间看看,可能就不合适了。。。。所以就有了结婚的时候讲究门当户对,离婚的时候发现各个方面都不合适。。。其实架构也一样,需要预见未来,适应变化。

我要搭建一个运维系统,每天人每天访问的次数也就100次,这个性能要那么高么?不需要,一个nginx加mysql足以支持。。。运维系统是否需要那么可用,服务挂了,不会影响外部客户,使用的人员就几个运维人员,挂了重启就好了。。。运维系统是否需要高扩展,就那么几个功能,还是相当稳定的。。。运维系统是否需要可靠性,可靠性是需要的,因为所有的服务器数据,机房数据,网络数据,slb数据等都存在数据库中,从而这块要做mysql的主备,要定时进行备份数据。。。运维系统是否需要安全,需要的,服务器的数据属于机密信息,从而需要用户名帐号进行登录认证。。。运维系统的规模多大,三台服务器足以,都不需要太好的虚拟机。

每个组件都是可以替换的,你可以把nginx换成httpd,你可以把jboss换成tomcat,都能达到同样的效果。

为什么程序员那么贵

再牛逼的架构都需要程序员来实现落地

再牛逼的需求都需要程序员来实现代码

其实。。。无论是架构,还是组建,还是系统的拆分,都是为了程序员能更快,更好,开发出更稳定的系统,看看发展历史,从结构化语言,到面向对象的语言,到软件过程,硬件的发展,无一不是为了配合业务的发展,无一不是为了需求更快的落地实现。

好像所有的环节都是围绕程序员展开,从几个方面来辩证:

1、 支持高并发的系统,需要程序员的代码水平和使用的各种框架

2、 运维人员吹嘘我维护了几千套系统,几千台服务器,其实和运维人员没太大关系,如果这个系统一分钟出现一次BUG,你试试他能不能运维

3、 运维人员吹嘘我维护的是银行系统,各种高可用,高安全,高可靠,其实和运维人员也没太大关系,系统又不是你写的,是从架构方面本身就已经高可用,我采用的主备模式,我采用的是负载均衡支持大容量,我使用的是分布式存储,三副本保证可靠,而各种成熟的组件出现问题的情况很少,重点就在于程序员写的那段代码是否稳定,是否可靠,是否支持扩展

4、 开发开发完程序代码,是否符合产品经理的需求?是否能进行测试,是否能部署,是否可运维,白盒监控黑盒监控是否能提供,快速迭代是否可以,一切取决于程序员

那么问题来了,运维吹牛逼吹啥。。。。好像啥都和他没关系。。。

为什么关注程序员的那么多?因为他们太复杂了。。。因为他们不可靠,因为他们性能不过高,因为他们不是高可用的。。。性能不过高,因为几个需求过来,不能快速开发迭代;不可靠,因为写出来的代码总有BUG,每个人都习以为常;不可用,所以有了程序员强制免费加班的传统。。。。

程序员那么牛,能一个打十个。。。为啥你开发的系统没人用?为什么你开发的系统带不来价值,为啥我加班这么多还不能晋升,为啥我这么努力。。。。为什么你还会输????这种问题少想,毕竟想多了头疼,这就是程序员头发越来越少的原因么???

哪里来的那么多复杂度

没有变化就没有复杂,我要是天天躺在床上思考人生,根本就不复杂,每天躺着就行。。。。这就是传统行业每天躺在床上数钱的原因,因为太稳定了,业务从来不发生变化。

一个态度的转变,会不会头疼。。。一个需求的改变改变,会不会头疼。。。一个业务的改变,会不会头疼

头疼就对了,如果你不头疼,说明你有一切针对变化的策略。。。软件系统为什么会复杂,因为业务在天天变化;为什么业务天天变化,因为市场需求在变化;为什么市场需求在变化我们就要变,这就是。。。商业业务

头疼是因为你对目前的情况不了解。。。你不知道如何应对,所以就有了架构。。。架构是用来预知未来,而提前防范,但是也不能泛泛而谈。。。。一切瞎逼逼的架构最后都上不了线,也是无效之举。

我要用最新的技术,我要用docker,你连docker的多机分布都没搞清楚,你敢上?

我要用最新的架构,我要用微服务架构,你连拆分的服务都没规划好,你怎么拆?

我要用集群,我要用分布式,你连运维能力都没有,出现了一个故障,几百台服务器去查找问题,去查找日志,莫非要把几百台服务器全部重启一遍,你怎么运维?

你的目标是什么?你是为了尝试新技术,用非核心业务试水,JUST DO IT

你的目标是什么?你为了为了稳定,这是核心系统,那么就要好好权衡权衡了

场景。。。很重要。这就是我们在学习一样东西的时候,首先要搞清楚她的使用场景。

带着镣铐跳舞。。。。你不但要识别未来,你还要熟悉每个组件的使用场景,你还需要知道团队每个人的能力,分配合适的任务。。。

如何在有限的条件发挥最大的价值。。。。这就是你要思考的问题了。。。

抬头走路,低头看路。。。。也是一种很好玩的状态。毕竟无知也是一种莫大的勇气。。。 带着镣铐奔跑,这是一种挑战,也是一种机遇。

进程和线程了解一下

进程是操作系统分配资源的最小单位,例如cpu,内存

线程是操作系统调度的最小单位

这就是为什么redis是单进程的结构,我们在要在一台机器上运行多个redis进程,因为进程只能调度到一个cpu上;而运行多线程jboss的程序的时候,在一个机器上运行一个jboss就好了,因为线程能在多个cpu之间浪啊浪。。。

这也就是在开发程序的时候,推荐使用多线程,因为一般我们开发好了,不会在一台机器上运行多个进程,因为这也增加了运维的复杂度。

——————————————

有很多朋友留言说:没有代码没有命令,其实应该看出来发展的趋势就是命令和代码会越来越少。。。因为网上一查一大堆,又没有啥太大的难度,很多的命令你看了,你也记不住。。。就算你看了之后当时记住了,过一段时间你不用,三天就忘记了。。。更多的是,你要经过你自己的思考,然后再去动手实践,毕竟知行合一也是很难,也是很复杂的。。。

——————————————

有朋友留言说:为啥删了,因为有个图片太丑了。。。感觉现在写文章也是带着镣铐跳舞了。。。有很多的约束,不能再随心所欲的瞎逼逼了。。。心塞。

这也是一种权衡与折衷。

——————————————

我可能在潜移默化中变成了那个自己最最讨厌的人了。。。现在沟通感觉都是心平气和,但是语言中却在怼天怼地怼自己。。。别人备份数据,我反驳了一番;别人排查问题,我有反驳了一番。。。。在追求极致的方法。。。肯定是因为。。。低层次的我在控制我,而高层次的我在旁观。。。本意是为了你好,但是我却脱离了实际,我忘记了存在很多很多的约束条件。。。

——————————————

本文分享自微信公众号 - SRE运维实践(gh_319dd73ec076)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-06-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券