程序员写的技术 FAQ 和杂文

之所有提一般处理难度是因为中间要经过复杂的处理的话就不适合 mysql sql来处理了。可以用编程语言了。数据源：oracle, ms sql server, mysql etc...目标数据库：Mysql这里使用二种工具：spoon and Mysql使用 spoon把原数据库表导入Mysq中做成镜像表。再从 mysql的镜像表转移到 mysql的目标表中。这个过程可以用 mysql sql和函数进行简单的处理。经过实践非常方便。对于个人来说要...

1，外网地址要有2，端口要正确3，白名单要添加，添加什么？通过 ip.cn 查询

nats 流服务，好像是有方法可以查看用 web 监控页面可以看到。但是 nats-server 我是没有找到办法。但是换个思路，可以通过日志一一看到所有主题的。只要启动时加上日志的配置，和存储路径。nats-server -DV -m 8222 -l ./logs/nats.log...

构造数据：> zadd tag1 3 value10> zadd tag1 4 value41> zadd tag1 5 value51测试：> zrank tag1 value41> zrange tag1 0 -1 withscoresvalue13value44value55> zr...

我们可以看一下Redis官方文档对Lua脚本原子性的解释。Atomicity of scriptsRedis uses the same Lua interpreter to run all the commands. Also Redis guarantees that a script is executed in an atomic way: no other script or ...

“架构师应该亲力亲为”称职的架构师应该通过示范领导团队。他能胜任团队的所有工作，网络布线，配置构建流程，编写单元测试，担任测试工作。对技术缺乏全面理解的架构师，只是个项目经理。架构师是业务团队与技术团队之间的接口人。他必须理解各种技术问题。优秀的架构师应该有能力发现问题所在，召集团队成员，向大家解释问题产生的原因，或给出解决方案，而不是寻找替罪羊。不能把技术决策和方向上的难...

“打造数据库堡垒”敏捷方法盛行使很多人认为在有需要时才设计应用是可行的，甚至是更可取的。提前展开全面综合技术设计的日子已经成为过去。新派观念提倡尽早地，频繁地部署应用；一行写进产品的代码比头脑中的十行更有价值。但是对数据库却不行。 尽管业务规则和用户界面经常变化，但是采集来的数据的内部结构和关系通常不会变化。因此，通过正确分析，首先从结构上定义好数据模型非常关键。数...

让大家学会复用可复用的框架的条件：大家知道它们存在    为了让公司内的开发人员和设计人员重复利用已有的设计、框架、函数库或代码段，必须先让他们知道这些资源的存在，以及在哪里可以找到相关的信息（比如文档、版本和兼容性等）。这里的逻辑很简单：人们不会寻找不知道的东西。当大家可以轻松获取这些信息时，复用的几率就会上升。    在公司内推广可复用资源的办法有很多。规模较大的团队可以通过 ...

先尝试后决策在最后时刻，和开发人员商量出解决方案，尝试一段时间。召开会议比较不同解决方案的优点和弊端。希望通过尝试大家对问题的解决方案有了共识。适合简单的问题。尝试两种或两种以上的解决方案，工作量会大，但比事后发现方案不合适，损失还是小的。...

“先确保解决方案简单可用，再考虑通用性和复用性”多数开发者开发的是专用系统，无限制的通用性对于他们的帮助不大。寻求通用性最好的办法是研究现有的具体案例，抓住问题的实质，从根本上得出通用解决方案。通过经验提炼的简单方案，远胜过不切实际的通用性。 “先简单后通用”原则可以成为最终的评判标准。设计组件的首要任务是抓住具体需求，满足需求。提炼通用性可以使我们更加接近问题的本质，...

“取舍的艺术”妄想实现所有需求（像瓦萨号一样），只会产生脆弱的，一无是处的架构。有许多工具可以帮助架构师做出取舍，最流行的是架构权衡分析方法（Architecture Tradeoff Analysis Method, ATAM）和成本收益分析方法（Cost Benefit Analysis Method, CBAM）。...

架构里没有大写的“I”自我可能是我们最大的敌人。    他们认为自己比客户更懂需求。    他们认为开发人员只是雇来实现自己想法的资源。    如果他们的想法遭至质疑，或者旁人指出他们忽略了他人的意见，他们会极力为自己辩解。我猜凡是有经验的架构师都犯过类似的错误。因为这些错误我都犯过，而且教训惨痛。 为什么会这样。 我们取得过优秀的业绩。成绩和经验促成了我们的自信...

“持续集成”应鼓励推广持续集成的方法和工具。是指一套频繁对应用程序进行自动化测试和构建的实践方法，以及确保测试和构建自动执行的相关工具。持续集成通常在一台专门配置的集成服务器上完成。得益于单元测试工具和方法，自动化构建工具。它可以提高公司和开发团队的工作效率，改善工作效果。...

使用“一千英尺高”的视图架构师都希望了解正在开发的软件质量如何。软件质量的外在表现是满足客户的需求，其内在表现则比较隐蔽，包括设计是否清晰，是否容易理解、维护和扩展。如果被人追问质量的定义是什么，我们通常只能敷衍道：“只要看到，我就知道”，可是我们怎么才能看到质量呢？ 在架构图里，系统是由若干个小方框组成的，方框之间的连线代表着各种含义：依赖关系、数据流、共享资源（例如总线）等。这种图...

“重视不确定性”不确定性可以促使你推迟决定，收集更多的信息，促使你用分隔和抽象的方法来降低设计决策的重要性。即分隔系统后，单一系统出现问题后的影响面减少。成本降低。代价的减少让我们容易做出决定。架构代表了那些形成系统的重要设计决策。其重要性由变更决策的代价来衡量。优良的架构能够从整体上降低设计决策的重要性，糟糕架构则会突出重要性。 如果出现两个合理的选择，架构师应该停下来，...

在业界，twitter 的 zipkin 和淘宝的鹰眼就是类似的系统，它们都起源于 Google Dapper 论文列表如下twitter : zipkin淘宝：鹰眼京东商城：HydraeBay：Centralized Activity Logging (CAL)大众点评网：CAT窝窝：Tracing唯品会：memcruy新浪微博：https://github....

做个读书计划，加快此书阅读。共 6 章，677页。1，45页2，181页3，162页4，46页5，134页6，109页初步定 70+页每天。第一天读到35页，第二天读230页，第三天读到300页，第四天读到567页，第五天读到630页，第六天读完。1，入门2，实践指南3，核心原理4，开发指南5，运维指南6，源码导读...

此图是学习 kubernetes 的入门小结。可能写的有不对的地方欢迎指出。还在深入学习。

掌握业务领域知识要懂技术，要掌握问题空间对应的业务领域知识。架构师的角色任务在于理解业务问题、业务目标、业务需求，并设计技术架构来满足它们。比如：保险行业适合采用面向服务的架构方法，而金额市场适合采用基于工作流的架构方法。能自如地运用企业高管（C-level executives）和用户熟悉的行业术语与他们沟通。更好的理解要解决的难题、有争议的问题、业务目标，以及数据和流...

“业务目标至上”成为业务部门和技术部门之间沟通的桥梁，周旋调解，兼顾双方的利益。用业务目标来驱动项目开发。业务目标和实际的开发条件应该成为架构师主持制定决策的参照系统。 架构师应该站在业务团队这边，拒绝开发团队选用价价不菲的软件和售后服务成本过高的技术。直观大图表、持续集成，频繁发布软件用业务目标驱动项目开发，才能保证软件开发团队的长远利益。...

“不要轻易放过不起眼的问题”问题刚出现时一般都不起眼，直到后期才会变得严重。当个人的经验和知识得不到其他团队成员的认同时，你的意见就会遭到抵制。大多数程序员都是乐观主义者。每个团队成员关注的侧重点不同。每个人身上都存在自己难以识别和接受的盲点和不足。 克服这些消极因素：1，组织团队一起来想办法管理风险。例如用跟踪 bug 的方法来跟踪风险。让大家都参与识别风险，...

“避免进度调整失误”项目改变计划会带来以下问题仓促决定的进度会导致拙劣的设计、憋脚的文档，可能引发质量问题，导致用户拒绝验收；仓促完成的代码，会直接导致最终产品的 bug 数量增加；紧张的测试进度会导致测试不充分，直接增加测试中可能出现的问题；以上几项都会引发产品质量问题，而解决产品质量问题的代价更高。 最终结果是成本不降反升，通常项目就是这样失败的。 Dava...

“量化需求”“速度快”不能算作需求，“响应灵敏”和“可扩展”也不能算是，因为我们无法客观地判断是否满足了这样的条件。但这些又确实是用户想要的。架构师的工作在很大程度上是要平衡这些需求之间的不可避免的冲突和矛盾，同时又使系统尽可能地满足它们。如果缺乏客观的标准，架构师就只能任凭挑剔的用户和偏执的程序员摆布。（“还不够快，我拒绝接受”和“还不够快，我不能发布”是他们的口头禅）易...

“以沟通为中心，坚持简明清晰的表达方式和开明的领导风格”架构师必须获得同伴的尊敬才能顺利开展工作。如果开发人员对项目蓝图和决策过程一无所知，必定会产生隐患。安排一位信得过的开发人员牵头，创造良好的合作环境，请大家共同验证你的架构决策。让开发人员参与架构的制订过程，他们才会买你的账。与其和开发人员对着干，不妨与他们合作。请记住，所有的团队成员（包括质量控制小组、业务分析员、项目经理，...

“我们常常忽略了自己在谈判”把自己当成工程师，而项目投资人明白他在跟你谈判。工程师总是想尽办法寻求合作，谈判者则绞尽脑汁占得先机。谈判时，绝不能在对方的第一个要求上妥协让步。其实，我们应该这样回答“真的需要吗？”这类问题： “单台服务器每天至少会崩溃三次，系统负载加重的话情况会更严重，没有第二台服务器，我们无法保证你给董事会做演示时一切正常。说实话，我们至少需要四台服务...

“故障终究会发生”硬件会出错，于是我们增加冗余资源来提升系统的可靠性。这样可以避免单点故障引起的系统错误，但同时也增加至少一台设备出错的概率。 软件会出错，由软件构成的应用程序自然也会出错，于是我们开发了监控程序，对应用程序报警。但监控程序也是软件，一样会出错。 人也会犯错，所以我们把操作、诊断和处理都变成自动化。降低了主动犯错的概率，增加了错误被忽略的概率。于...

“关键问题可能不是出在技术上”这只是一种可能。只是解决一种可能问题的方法：项目是由人完成的，人才是项目成败与否的基础。主要问题是如何帮助团队成员完成项目。这才是主要问题。如果有团队成员拖项目后腿怎么办？对话尊重他人，给予团队成员充分的信任。1，不要把对话当成对抗。2，不要带着情绪与人沟通。3，尝试通过沟通设定共同的目标。...

“简化根本复杂性，消除偶发复杂性”根本复杂性（essential complexity）指问题与生俱来的、无法避免的困难。偶发复杂性（accidental complexity）是人们解决根本复杂性的过程中衍生的。架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。 但现实中解决根本复杂性的同时，很大的机率会引入偶发复杂性的。所以我们要尽量避免这种事发生。...

“项目需求重于个人简历”摘自书，也有我的示例。作为工程师，我们常常要向客户/老板推荐技术，手段，甚至方法论来解决问题。但有时我们心里不是想寻求解决问题的最佳方案，而是希望借此丰富自己的简历。这样做很可能得不偿失。 信誉远胜过时髦的编程技巧和流行的范式。掌握最新的技术趋势，与时俱进固然重要，但不能让客户为此买单。作为架构师，职业操守绝不能忘。公司托付重任给你，是期望你尽职恪守...

      比例模型是深入人心的展示方式，但是不管某个 PPT 图表中的彩色方块多么好看，多么简单易懂，它也无法完全代表一个软件的架构。它只能是该软件的架构的一个视图，而非全部。软件的架构并没有固定的展现形式，你所看到的每一个视图的背后都是架构师所做的层层抉择。一个视图包含了哪些部分，排除了哪些部分；用特殊形状和颜色强调了哪些部分，又有哪些部分被泛泛地一笔带过，甚至直接忽略，这...

“分析客户需求背后的意义”不要得到需求就直接实现，而不经过思考。 架构师可以通过询问客户，分析客户要求的功能和需求的真正意义，定位真正的问题，从而提出比客户的建议更好、成本更低的解决方案。通过关注问题的真正含义，理顺需求的轻重缓急：把最有价值的需求摆在第一位。 合作客户合作重要于合同谈判与客户交流时，引导客户回答为什么的问题。避免与客户讨论技术上的具体实现，应该...

“架构设计要平衡兼顾多方需求”系统建模定义接口划分功能模块套用模式优化性能系统的安全性易用性（usability）产品支持发布管理部署方式解决以上问题的技术问题和流程问题。充分考虑相关各方的要求，只有这样才能确保需求说明书的完整性。架构设计要实现的一组最终目标通过逐步分析相关各方的需求得到。这个分析过程应该贯彻到软件开发的整个过程中。设计...

“提前关注性能问题”商业用户的需求主要表现为对功能的要求。系统的非功能特性则由架构师负责：包括：性能表现、灵活性、持续正常工作时间、技术支持资源等。尽早反复地开展性能测试可以缩小问题的可疑范围。坚持技术测试是需要耐心和毅力的：    无论是搭建合适的测试环境    采集适当的数据集    编写必要的测试用例都须要投入大量的时间。提前关注性能带来的工作量是非常大的...

“不要在一棵树上吊死”大家不愿承认世界是混乱的。常常期望用单一的，简单的方法来解决现实问题。怕遇到错综复杂的依赖关系，担心数据更新无法同步，额外的维护开销。示例：数据集市的设计...

 为满足软件的各项精确定义的功能、性能需求，符合文档化的开发标准，需要相应地给出或设计一些质量特性及其组合，作为在软件开发与维护中的重要考虑因素。如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品质量就是高的。 软件属性可用做评价准则，定量化地度量软件属性可知软件质量的优劣。软件质量是各种特性的复杂组合，它随着应用的不同而不同，随着用户提出的质量要求不同而不同。因些，...

“草率提交任务是不负责任的行为”以维护流程通畅为重，以浪费他人时间为耻。    要做到这一点，务必在系统内实现完善的自动测试功能。    避免把有缺陷的代码丢给同事。    如果测试依赖于外部系统，或者需要访问数据库，则要重新设计可以在本地完成，        如 Mock 或 Stub 对自己的行为负责对他人负责。...

“不存在放之四海皆准的解决方案”软件方案设计过度，偏离了实用性和眼前的基本需求；解决性能问题时，提出的建议不合理。不存在万能钥匙，架构师必须培养和训练情境意识，才能更好地设计架构和解决问题。以上都是常见问题。我们要小心应对。...

高复杂度不可避免吗？当一个复杂的领域——例如逻辑问题优化、实时可视化，或者其他需要更高级的应用程序逻辑时，很自然地，我们会将领域中很复杂的想法带到代码的实现过程中，并且认为这是不可避免的事实。 这种解释不一定是正确的。复杂的领域并不一定要求技术实现也一定是复杂的。事实上，作为一名开发人员的责任就是简化问题，并且编写简单的代码。即使整个系统的功能很复杂，也并不意味着最底层的代码单元也应该...

“起立发言”架构师更需要与人打交道，让开发人员接受设计模式，还是向管理层解释购买中间件的利弊，沟通是达成目标的核心技能。 在两人以上的场合发表意见时，请站起来。起立发言方便与每位听众保持视线接触。眼神交流、肢体语言等表达方式在沟通中的作用不可小视。    能更好的发现听众的问题，注意反馈，自我调整。起立发言还可以更好的控制语气、语调、语速和嗓门，让你的声音传得更远。...

“一行代码比五百行架构说明更有价值”架构说明书（specifications）很重要，因为它描述了构建系统的模式。软件项目的最终目标是建立生产体系（production system）牢记设计只是达成目标的手段，不是目标。我们的目标是可工作的代码。架构师应该与团队成员合作，共同作出决策，修改设计以符合实际情况。没有天生完美的设计，所有的设计都要在实现的过程中逐步完善。 ...