架构

　　在看了王概凯作者的架构漫谈之后，感触颇多，在这里就软件架构师如何工作进行一些讨论。 　　王概凯作者的网址：https://www.infoq.cn/profile/1279517/publish 　　在生活中经常会谈及或者听说架构师这个职位，那么什么是架构师呢？架构师并不只是做架构工作的那么简单。如果一个人把按时解决别人的问题当成自己的问题的时候，潜意识里会形成一种对时间的恐惧，这种恐惧会使我们想方设法、不择手段的完成工作。在这种情况下是不可能成为架构师的。要成为架构师必须超越这种恐惧，看清楚我们解决的是别人的问题，而不是我们自己完成工作的问题，如果我们把完成别人工作当成自己的最大利益，这个对时间的恐惧自然就会消失，这个时候就自然而然的开窍了，就知道怎么去发现问题了。只有做到这一点，才能在自己所服务的领域建立起自信，成为一个合格的架构师。 　　作为一个架构师，要善于发现问题，主动找上你的问题都不是最根本的问题。要根据别人的利益来发现最根本的问题。“如果问题不解决，究竟谁会有利益的损失？ 如果问题解决了，究竟谁会有收益，谁的收益最大？” 回答了这两个问题就找到了问题的主体。只回答一个是没有用的，因为很多时候这个世界的事情，权责是不对等的。明白了这两个问题，我们只要让事情权责对等起来，让每个人为自己的权利产生的结果负有义务，大部分时候我们自己根本就不需要做什么，问题就都解决了

通过阅读了王概凯老师的《架构漫谈》，我对架构的产生，架构的作用，技术和架构之间的关系，以及架构师有了更加清楚地了解。 文章中很清楚，通俗易懂的讲述了架构产生的由来，以及概念的由来，让晦涩难懂的知识点，变得通俗易懂，架构就是把一个整体切分成不同部分，有不同角色完成这些分功，通过建立不同部分相互沟通的机制，是这些部分能够有机的结合作为一个整体，并完成这个整体所需要的所有活动。其中切分不同的部分又有广度和深度，一个大面饼可以切分，相对于人的话，时间的前后也可以划分，那么就相对的也许好划分，架构也就随之而有了。 王概凯老师又引了“名相”这个概念，相是作用，而名是为了指代这个作用而产生的名字，这个就是古代的概念。同时王概凯老师又相当准确的阐述了什么是真正的概念。一个物体不是通过他的外观而产生，而独立于世界的，是通过他的内在作用，比如杯子“单手持握，可以盛有少量液体或物体的容器”，这就是其的作用而不是“一个侧边有把，内空”这就是做架构前需要先了解这个物体的内在作用，才能更好的切分，更好的去划分。 那么做架构，更重要的是认清这个系统真正的问题主题是谁？并不一定是用户，需要事先做好调查，王概凯老师引了一个软件工程领域熟知的例子“用户给产品经理提出要一把锤子”，如果相对产品经理，那么就是一把锤子，如果相对开发者，一个石头就应当可以完成锤子的任务，而用户想要的是能够解决更加方便顶入钉子

　　说起软件架构师，我只能说我几乎没有任何了解。听名字可以看出软件架构师是管理软件架构的，但是软件架构又是什么？昨天，软件体系结构这门课开课了，老师提到了软件架构，课后我又看了看架构漫谈的几篇博客（ https://www.infoq.cn/profile/1279517/publish ），可以说是简单的了解了软件架构以及软件架构师的工作。 　　架构的英文是 Architecture，在Wikipedia 上，架构是这样定义的：Architecture (Latin architectura, from the Greek ἀρχιτέκτων arkhitekton"architect", from ἀρχι- "chief" and τέκτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures。这句话的翻译为中文是：架构(拉丁当时从希腊ἀρχιτέκτωνarkhitekton“架构师”,从ἀρχι——“首席”和τέκτων“建设者”)是过程和产品的规划、设计和建造建筑物和其他物理结构。博客里举了早期社会分工合作的例子，人类通过将生存这一目标分解为各个小目标，有人负责种田

下面对漫谈架构的每一章进行一个总结 一）第一篇：讲的是到底什么是架构， 在我看来 ： 就是 把一整体划分为不同角色， 各自完成自己的部分 ， 最后有机的融合在一起 。 然后通过一个早期的例子来笼统地概括他的出现。 在最早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，整个人类都是独立的个体，不相往来。为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，可是人每天生活的基本需求没有发生变化，还是衣食住行等生活必须品。但是一旦多人分工配合作为生存的整体，力量就显得强大多了，所以也自然的形成了族群：有些人种田厉害，有些人制作工具厉害，有些地方适合产出粮食，有些地方适合产出棉花等，就自然形成了人的分群，地域的分群。当分工发生后，实际上每个人的生产力都得到了提高，因为做的都是每个人擅长的事情 （二）第二篇：讲的是认识概念。架构实际上解决的是人的问题， 举个例子， 看到一个东西，比方说杯子， “ 杯子 ” 就是一个名字，指代的看到的东西就是相，就是事物的相状。我们一听到 “ 杯子 ” 这个词，脑海里就会浮现出一个杯子的形象。而 “ 杯子 ” 这个词，是用来指代的是这个相状的，叫做名。合起来就叫做 “ 名相 ” 。每个概念 都是因解决问题而产生的 ， 最后 我们把解决问题的解决方案， 命名了一个名字 ，这个名字就是概念。

　　通过阅读王概凯的架构漫谈和查阅一些其他资料，我大致了解了一下软件架构师的一些相关知识。 　　什么是架构呢？在架构漫谈中这样说道：把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。那又应该如何做好架构呢，最重要的有两点。一是识别问题，要正确的认识问题，需要问两个问题：这是谁的问题，有什么问题。二是要架构切分，架构的切分的导火索是人的负载太重。架构的切分实际就是对stakeholder的利益进行切分或合并，使得每个stakeholder的权责是对等的，每个stakeholder可以为自己的利益负责。它的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。 　　所谓架构师，通俗的说就是设计师或结构设计者，这些定义如果用在建筑学上，则是很容易理解的。在软件工程领域中，软件架构师实际上就是软件项目的总体设计师，是软件组织新产品的开发与集成、新技术体系的构建者。软件架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本

　　在谈如何工作前，我认为首先要谈谈工作的内容是什么，或者说是为什么而工作，工作的最终目的是想实现什么目标。 　　软件架构：根据要解决的问题，对目标系统的边界进行界定，并且对目标系统按照某个原则进行切分。之后对其设立沟通的机制。最后使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。最重要的最后一点，不论我们做什么，最终都是为了让人类本身受益，不管是直接的还是间接的。 　　说完工作的内容，为什么而工作，工作最终的目的是实现什么目标。接下来就要步入正题，来谈谈软件架构师如何工作，再有就是如何快速高效的工作，并且最终完美的实现当初的目标。 　　一个软件架构师如果想要快速的进入工作状态，并且能够快速的打开解决问题的思路，首先就要对问题中的大多数的新旧概念有一个大的把控，和比较好的理解，做到这几点，问题基本上已经搞定了一半了，明白概念背后的含义，利用对概念的理解，快速的进行学习。这样能够很快的识别和定位问题。当然，既然已经明白了真正问题的所在，解决起来就会相当得心应手喽。 　　在成功找到解决方案之前还有一个非常重要，说难也不难，但是说简单也不简单的事情，这个事情就是，寻找问题的主体，即真正要被帮助解决该问题的人，前面说到的是有什么问题，这一段说的是谁的问题，前面的问题不论你解决的再好，但是如果你没有找对主体，那么也只能说是白干一场。所以说问题如果被比喻成是心脏

　　摘自百度百科：所谓架构师，通俗的说就是设计师或结构设计者，这些定义如果用在建筑学上，则是很容易理解的。在软件工程领域中，软件架构师实际上就是软件项目的总体设计师，是软件组织新产品的开发与集成、新技术体系的构建者。 　　正如《架构漫谈》作者所说，架构师必须是一个组织的领导人。软件架构师的主要任务并不是从事具体程序的编写，而是从事更高层次的开发架构工作，因此软件架构师需要有良好的组织管理能力以及一定的实权。 　　要想成为一名合格的软件架构师，首先要明白架构师是去帮助别人解决问题，而不是自己完成工作，并且工作完成与否是别人说的，不是自己，所以身为一名架构师要把完成别人工作当成自己的最大利益，要努力地越来越多的人依赖你 认同你。 　　架构师要学会发现问题，把别人的问题当成自己问题来思考并且解决问题。同时架构师是一个领导人，他所考虑的不光是解决问题，他更要考虑如何用最小的成本获取最大的利益。架构师是在不断的平衡与调整别人的利益过程中让组织成员都能够积极地为服务。所谓架构师，不光技术要好，还要有良好的管理能力。 　　通过阅读GItHub一篇文章，我了解到软件架构师的日常与必备技能，并把每个技能简单概括如下。 日常： 定义和确定所需的开发技术与平台； 定义开发标准，如编程标准、工具、审核流程、测试方法等； 对确定和理解业务需求提供支持； 设计系统并根据需求做出决策； 对架构定义

　　学习计算机技术的过程中往往会遇到一个问题：这个东西是干什么的。如果能弄清这个问题的答案，那就能理解我们所要学习的技术的整体架构。在这就有了架构这个概念。 架构是什么 　　在弄清架构是什么之前，更需要弄清我们日常生活中常见事务的过程，这是因为计算机是个神奇的领域，在需求我们的创造力的同时，更需要我们的逻辑感，所以软件工程师往往会用现实生活中的东西来作为灵感来源，方便他们为手上的工作做出最精妙的设想。从原始社会开始就有了分工这个概念，男人狩猎女人采摘，使得整个氏族能有条不紊地发展起来，这对于古人类学家来说就是一种社会架构；而随着人类社会的复杂化，这种简单的工作划分就完全不再适用了，而到了现代社会，估计就人类学家而言这个社会架构也就像他们这一辈子都无法完全研读的一本百科全书了。 　　计算机是人类为了降低自己的工作复杂度而产生的工具，也不知道为什么，在创造这个机器的时候，人们总是有意无意的使它更接近于现实中存在的东西或者逻辑，面向对象技术就是最好的例子，这也是软件工程师为了把现实映射到计算机里的伟大实践。如果计算机工作的过程只是二进制的不断延伸，那估计没几个人能用计算机。所以，我们现实中存在的架构这个东西也就顺理成章地在计算机里面产生了。 软件架构师能力一——判断 　　架构好比分层的鸡尾酒，相互之间不能过度的交流，否则会混成一杯平凡的酒，如何判断出某种液体适合这种酒就是调酒师的工作了—

软件架构师如何工作 阅读了王概凯老师的架构漫谈九篇博客，从中了解到了什么是架构、什么是软件架构师以及软件架构师应如何工作。软件架构师首先要搞明白问题的主体，之后把问题进行拆分形成架构，是工作人员的效率更高。架构师还必须要明白，所给出的解决方案 -- 架构的分拆、合并方案，只有让问题的主体的权责对等，才能够真正的解决别人的问题。一般明白了问题的主体，以及主体的利益所在，做到这一点也没有问题。 架构产生的动力是事情必须由人执行的工作，每个人的能力、时间有限，人对目标系统有更高的要求，目标系统的复杂性使得单个人完成这个系统很困难。架构是根据要解决的问题，对目标系统的边界进行界定，并对目标系统按某个原则的进行切分，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间，并对这些切分出来的部分，设立沟通机制，这得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。 一名软件架构师，必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处，反过来，具备架构师能力的组织领导人，一定是一个很好的领导，这个组织一定是很健康向上的，因为每个人的权利和义务就是比较均等的。并且这类领导对于组织成员权利和义务的对等状况会非常的敏感，会及时的调整组织架构，在问题发生之前就解决了。架构师要能够发现“是谁的问题”

RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。RESTFUL适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。 REST（英文：Representational State Transfer，简称REST）描述了一个架构样式的网络系统，比如 web 应用程序。 在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。 原则条件 REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。 Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。 在服务器端，应用程序状态和功能可以分为各种资源