逐梦如风-毕康

es集群入门全文检索lucene的基本架构文档字段 k-v词标记:(词,开始-结束,类型)输入分析分析器，标记过滤器，字符映射器索引和查询评分和查询相关性 es基础es基础概念索引文档文档类型节点和集群分片-数据分成小片副本--主分片修改索引，福分片备份时光之门--节点状态控制es 基础概念需要注意的不同的文档类型不能为相同的属性设置不同的类型。例如,在同一索引中的所有

97条架构建议-简单-开发-决策根据投资回报率进行决策我们对项目的每一个决策—无论是技术过程，还是人与人相处，都可以看作是一种投资形式。我们可以使用投资回报率作为衡量架构决策的标准之一。确保架构的务实和恰当的架构师首先是开发人员不管设计方案做的如何优秀，决定实现是否成功的重要因素之一是开发人员愿意开发。架构师的主要目标是创建可行，可维护的解决方案，并能够解决当前的问题。能够帮助开发人员解决问题是很重

97条架构建议-规则-可用-数据数据是核心数据是系统的核心，如果以为编程是函数，方法对象的集合和只从这方面考虑问题就不会全面的看问题。从数据结构的角度理解系统能够让我们更加容易的，清晰的了解系统， 略过了许多不必要的细节，我们能把握系统的核心。每次数据结构的调整，将会引起较大的变动，对待数据不能不慎重。可行走的骨架我们做一个权衡，分析系统，考虑现在和未来，同时做一个可行走的骨架，然后不断的迭代和增

97条架构建议-边界-团队-决策边界架构师应该聚焦在边界和接口，大型的软件的边界有时很难界定而且各个领域之间互有纠缠，开发出高内聚低耦合的软件是不易的，我们可以采用一个情境的地图去描述这些边界，能够关注这些部分，开发出高内聚低耦合的软件团队诸事说易行难。架构师容易陷入吹牛皮的状态。其实架构师和架构师的团队一样重要帮助团队有利于项目的展开1 确保开发人员所需工具和工具的熟练度2 确保开发人员的技能，

97条架构建议-现实-观察-两面现实程序世界是可控的有逻辑的，而现实世界却是不可控的。可能出现各种意外的情况。我们设想的完美世界可能在崩溃，我们需要接受现实，然后分阶段去改良我们的代码。观察我们已经进入了分布式，松耦合的时代。松耦合的时代的特点是系统足够灵活，可能因为一点点小变动就支离破碎。设计的演变的，是随着时间不断的灵活变化的。架构师不能妄想掌控一切，这会设计出紧耦合脆弱的解决方案。设计系统我们

97条架构建议-空白-行话–情境留意架构中的空白部分软件系统由相互依赖的程序组成，我们装备这些程序和方法见的关联叫做架构我们一般会通过简单的图形表示系统，这是种抽象和概括。其实系统远比这复杂，还有许多空白需要填补。包括硬件的问题。在确定主干后，我们应该考虑更多，考虑越多我们最后遇到的问题就越少。学习软件专业的行话每个行业都有它自己的行话，软件行业也不例外。架构和设计模式就是架构师的行话。架构和设计模

97条架构建议-大厦-混合开发-性能大厦摩天大楼是没法伸缩的。不爆炸式的软件部署是行不通的。我们应该是逐个部署系统组件。优点如下：1 将风险分散到各个时间段2 迫使我们设计清晰的组件接口，提高系统的一致性和降低耦合性我们可以尝试“尽早发布” 和递增式部署的方式开发软件。混合开发混合开发早就来临了~~。Rest架构风格已经普及~混合开发的时候我们需要注意编程的规范，否则将会导致混乱。架构师需要

97条架构建议-道德-管家-规模控制规模规模是软件的大小。规模的组成项目完成时间人工和资源功能质量难度风险遵守哪些约束条件规模大一倍，项目失败的概率增加十倍的原因1 作者的直觉，更多资源，更多的沟通2 估算与科学计算相差甚远缩小和控制项目的规模1 抓住正则的需求。客户的需求+公司的效益。2 分而治之。大项目划分为小项目3 设置优先级。4 尽快交付敏捷开发提倡：最简单有效的东

97条架构建议-信任程序员-时间-架构专业信任程序员你也是程序员过来的，程序员可能擅长写代码，却忽略一些沟通和协作性的问题，又或者是他们实在是做的很烂，你可以指导他们，我觉得最好的办法是使他们有参与感，主动的提出问题。时间的力量时间带走一切曾经看起来美好的东西，大浪淘沙。如何和时间有效沟通选择值得投入精力的工作,明白重点简单原则别跟以前的工作过不去--别自卑，昂步向前争议话题：是否该设立架构专

97条架构建议-多尝试-掌握领域知识-设计先尝试再建议架构需要详细的分析，分解业务再做决策先接触项目在进行架构选型，这个时候你得尽可能多的收集业务相关的信息。你也可以推迟架构决策，尽可能多的收集项目相关的信息，因为确定架构后再去调整它的代价是最大的。掌握领域相关的业务知识对架构师来说，技术知识基础，快速的学习和完善你的业务领域知识，才能让你做出尽可能好的决策。熟练的业务知识，有助于沟通，增加客户的信

97条架构建议之持续集成-进度调整-取舍持续集成尽早构建，持续集成，每次构建和集成都保证系统的稳定性和可用性。可以提高软件的开发效率避免进度调整失误导致项目失败的原因很多。有些情况我们可以通过加班，等等解决~~最可怕的是时间不变，任务量增加，或者任务量不变，截止时间提前。有种错误的观念：加快速度可以降低成本。由此你可能必须放弃一些看起来不太重要的任务，比如单元测试之类的，就算交付时间不变也要增加

97条架构建议-业务目标至上-简单可用-亲力亲为业务目标至上业务目标驱动，架构师应该在实际的业务目标和实际的开发条件下制定决策系统架构师预估商业价值，避免技术决策造成经费超支建立反馈回路：大图表持续集成频繁发布先确保解决方案简单可用，再考虑通用性和复杂性不能一味强调通用性而不考虑具体应用，从具体中提炼出通用的解决方案先保证方案简单可用，再考虑从业务分析出通用性和复杂性。架构师应该亲力亲为架构师

97条架构建议-重视数据库-确定不确定性-关注细节打造数据库堡垒业务变化，人员变化，可是数据库却很少变化。牢固的数据模型一直会很少变化。牢固的数据模型真的是太重要了。牢固的数据模型需要既要保证数据的安全性，又要保证可扩展性。牢固的数据模型要素隔离来自应用层的bug遵守引用完整性的规则使用域约束恰当的键阻止无意义的关系必须在开始构建数据库的时候，深刻理解业务的需求。确定的不确定的问题确定你的

97条架构建议-架构平衡-负责-多方案架构设计要平衡兼顾多方需求软件架构常考虑的：系统建模，定义接口，划分功能模块套用模式，优化性能安全性，易用性，产品支持，发布管理，部署方式等问题除了上面的技术架构外，软件架构师还必须考虑各方的要求和利益。只有充分考虑了各方面的要求，才能确保需求说明书的完整性。架构师实现的一组最终目标可以通过逐步分析相关各方的需求得到。这个分析过程应该贯彻整个软件开发过程。

几行代码可能比架构更管用设计拥有的无穷魅力，我们容易陷入其中，无法自拔。我们最后会确定架构的最终产物，架构说明书(或者图稿)。我们既需要了解上层组件之间的交互，也需要了解组件内部代码的组织，这样我们不会使我们的架构脱离实际。应该珍惜自己写代码的时光，它不是在分散精力，它是在扩展你的视野和微观世界。不存在放之四海而皆准的方案不存在放之四海而皆准的方案我们需要根据系统的实际情况去分析，决定选择哪种方案。

架构决定性能架构决定性能。架构才是影响应用的性能和可伸缩性的决定性因素。我们无法通过简单从架构调优和简单的更换软件解决架构问题。分析客户背后的意义我们应该询问客户，分析客户要求的功能和需求的真正的意义，定位真正的问题，从而提出比客户的建议更爱好，成本更低的解决方案。理顺轻重缓急，把最重要的放在第一位。我们需要引导客户说出为什么，因为有时候客户总是以为这个原因是不言而喻的。起立发言架构师应该重视推销自

故障终究会发生硬件错误，可以增加冗余，避免单点错误软件也会出错，我们增加额外的监控程序人无完人，我们把操作，诊断和处理都编程自动化。降低了主动犯错的概率，却增加了错误被忽略的概率。我们为自动化增加监控，结果是更多的软件，导致更高的故障率。系统故障终究会发生，隐患无法彻底消灭。我们需要事先设计防范故障的模型，否则我们无法应对威胁系统安全的意外情况我们常常忽略自己在谈判我们真的常常忽略自己在谈判。我们可

软件架构师应该知道的97件事之复杂性-技术之外-简明沟通简化根本复杂性，消除偶发复杂性业务的复杂性是必然的，我们需要对业务进行分析，对业务的复杂性进行解耦，解耦的过程中有可能产生偶发的复杂性。理科生有个通病，我们喜欢解决复杂的问题，并由此产生自豪感。这个毛病在软件开发上可能带来致命的缺陷。后期维护成本巨高，这点我们得警惕。复杂大多人都会，如何化复杂为简明，这需要高超的技艺了。关键问题可能不是出在技术

架构师应该知道的97件事读书笔记之客户需求重于个人简历有时候我们很虚荣，一味的追求新技术，在一门技术还没有成熟前使用它风险是很高的。我们可能会因为个人简历，个人爱好，个人兴趣，和各种狂热，过分的使用新技术，而忘了客户的需求，忘了分析业务的本质想想新技术是否满足 ：数据一致性的站点、服务、数据系统，功能、性能、扩展性、维护性、安全性、可用性呢？