《架构漫谈》系列读后感
这几天，读了老师推荐有关架构的一篇系列文章《架构漫谈》，其中通俗易懂的语言，风趣幽默的风格，形象明了的对比形式让我对架构有了更进一步的了解。
何为架构？最早期社会我们一个人就可以完全独立生活完成衣食住行所有事情，随着需求的增加，比如说人类延续，人们开始群居。接下来人们发现各自有各自的长处，有的人种田厉害，有的人制作工具厉害，有些地方适合产出粮食，这就导致分工，各自做擅长的事情。由于每个人的精力，时间，能力皆有限，当需要完成一个大的工程的时候，人们必须各取所长合作完成，人们如何组织这项工程，如何安排合适的人做合适的事，在最高效最稳定的情况下交付既定任务，这样“架构”就应运而生了。总结而言，架构就是：1.根据要解决的问题，对系统的边界进行界定。2.并对目标系统按某个原则进行划分。划分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。3.并对这些切分出来的部分，设立李沟通机制。4.根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
怎么初识架构？认识概念，我们从前面知道，架构是为了解决人的问题，那么沟通便显得尤为重要，中华文化博大精深，每一句话可能有多重理解，所以我们要对概念有一个初步的把控，最主要的当然就是识别概念，识别别人提出的问题。比如有人提出要求“我需要一个锤子”，在不清楚具体问题的情况下，我们是无法定夺怎么恰到其份地解决问题，如果他是钉钉子可以只提供一个小锤子，如果他是装修砸墙那么需要提供专用大锤。架构师初步要解决的是识别问题并提供解决方案。
如何做好架构呢？切分，我们要对整个项目需求进行切分，还要把控对于利益的调整。一旦确认问题的主体，我们接下来会发现如下问题，某个或者某些利益相关人负载太重，或者时间上空间上负载太重，或者某个，某些利益相关人的权利和义务不对等。所以我们需要在一定原则上进行切分，第一是自然就无法切分的部分，第二是不违反人性。随后就是一系列建模和组织架构了。
初识软件，软件的历史，实际上可以说是用机器模拟人的历史。简而言之，可以说是在成本保证的情况下，为了简化某些工作而让计算机代替人执行一些特定任务，提高生产力的产品。也正是由于源源不断的需求，使得软件规模不断扩大，给软件的使用性能造成影响，所以软件架构也随势而生，其根本目的也是同样，提升参与人的利益，减低成本。
那软件架构要解决的“性能问题”是什么问题？业务？计算机本身？为了进行分辨，我们必须了解虚拟化业务必须完成的事情是什么，代码是如何运营的，之后就是针对问题提出并实施解决方案，在这些的前提之下，我们必须有一个根深蒂固的概念，那就是架构总是为了简化问题的，而不是使得问题复杂化，所以软件架构又被定义为软件因为流量增大而分拆成不同的运行单元，在不同的机器上部署所形成的架构，属于软件架构。每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。
架构师，首先，架构师的前提条件，那就是发现问题并提出有效解决方案处理问题的人，架构师一定拥有丰富的经验和技术，而且他是调整利益平衡利益的人。之后，从架构的角度写代码，核心是分层，将业务，技术，逻辑处理分成各自耦合度相对降低的层次，让软件的运营成本降至最低，而且利于维护。最后就是理清技术、业务和架构的关系了。技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。有了更好的技术，效率更差的技术就会被淘汰，一切都遵从人类的利益诉求—也就是业务。再者，在解决同一个业务的问题的前提下，更高效，更低成本的技术将代替其他技术。所以架构师应该承担起解决业务问题的角色，也需要具备识别技术采取技术相应的能力。