程序员写的技术 FAQ 和杂文

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

如何运行 nats-server 并生成日志内容？如何清理日志文件，并继续写入新的日志？此文解决的是这个问题。本文为原创https://download.youkuaiyun.com/download/wide288/12588142

Redis Lua解释器加载以下Lua库：base库 table库 string库 math库 struct库 cjson库 cmsgpack库 bitop库 redis.sha1hex功能。 redis.breakpoint and redis.debugRedis Lua调试器上下文中的函数。不可以使用全局变量，如果使用会报错。一定要用，要使...

任钢 著第1部分，微服务体系概述是顺应时代的发展产生的。微服务架构（MSA）的定义微服务是一个完整的体系，并说明了什么是体系。（这个好）第1章，微服务概述关于微服务的一些辨证关系辨证这个词在以往的文章中出现的比较少。结构化分析设计，面向对象分析和设计，重构设计，领域设计，敏捷软件开发 = 只做好一件事。第零个时代：主机时代第...

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

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

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

“架构决定性能”所有产品和架构都必须遵循分布式计算和物理学的基本原理：运行应用和产品的计算机性能有限，通过物理连接和逻辑协议实现的通信必然有延时。因此，应该承认架构才是影响应用性能和可伸缩性的决定因素。性能参数是无法简单地通过更换软件，或者“调优”底层软件架构来改善的，我们必须在架构的设计（或重新设计）上投入更多精力。不是绝对，但架构解决问题是绝对的。...

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

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

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

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

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