架构本身就是一个伪命题，因为很多东西的考虑是一种权衡，也是一种选择，并且含有各种约束条件。
架构可以从各个角度来看，可以从业务，从而有业务架构；可以从开发角度，从而有逻辑架构，有开发架构；可以从运维角度看，从而有部署架构。
架构
无论你想与不想，其实架构就在娜里。
写程序的时候，你会涉及到各种业务系统的架构，系统之间的拆分，一个大而统的系统拆分为各个子系统，子系统中又划分为各种组件，在开发的时候，又可以在各种框架中进行开发。
而架构又能解决什么样的问题？架构主要是根据需求，识别其中复杂的地方，从而对这个复杂的地方进行设计。
架构应该追求什么？在各种架构中，都追求高性能，高扩展，高可用，高可靠，安全度高，成本低。看看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之间浪啊浪。。。
这也就是在开发程序的时候，推荐使用多线程，因为一般我们开发好了，不会在一台机器上运行多个进程，因为这也增加了运维的复杂度。
——————————————
有很多朋友留言说：没有代码没有命令，其实应该看出来发展的趋势就是命令和代码会越来越少。。。因为网上一查一大堆，又没有啥太大的难度，很多的命令你看了，你也记不住。。。就算你看了之后当时记住了，过一段时间你不用，三天就忘记了。。。更多的是，你要经过你自己的思考，然后再去动手实践，毕竟知行合一也是很难，也是很复杂的。。。
——————————————
有朋友留言说：为啥删了，因为有个图片太丑了。。。感觉现在写文章也是带着镣铐跳舞了。。。有很多的约束，不能再随心所欲的瞎逼逼了。。。心塞。
这也是一种权衡与折衷。
——————————————
我可能在潜移默化中变成了那个自己最最讨厌的人了。。。现在沟通感觉都是心平气和，但是语言中却在怼天怼地怼自己。。。别人备份数据，我反驳了一番；别人排查问题，我有反驳了一番。。。。在追求极致的方法。。。肯定是因为。。。低层次的我在控制我，而高层次的我在旁观。。。本意是为了你好，但是我却脱离了实际，我忘记了存在很多很多的约束条件。。。
——————————————
1006
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
