https://puncsky.com/hacking-the-software-engineer-interview#what-is-architecture
架构师需要具备的几项技能
http://blog.cleancoder.com/uncle-bob/2016/01/04/ALittleArchitecture.html
https://javax0.wordpress.com/2016/05/04/architects-dont-decide/
业务理解和抽象能力
NB的代码能力
What is architecture?
Architecture is the shape of the software system. Thinking it as a big picture of physical buildings.
- paradigms are bricks.
- design principles are rooms.
- components are buildings.
Together they serve a specific purpose, like a hospital is for curing patents and a school is for educating students.
Why do we need architecture?
Behavior vs. Structure
Every software system provides two different values to the stakeholders: behavior and structure. Software developers are responsible for ensuring that both those values remain high.
::Software architects are, by virtue of their job description, more focused on the structure of the system than on its features and functions.::
Ultimate Goal - saving human resources costs per feature
Architecture serves the full lifecycle of the software system to make it easy to understand, develop, test, deploy, and operate. The goal is to minimize the human resources costs per business use-case.
1. 好的架构师，一定是好的程序员
- 没写过N年代码，何来指点江山？
- 没做过N年架构实践，何以指导避坑？
- 只有框架，没有细节，何以服众？
bad case：项目失败了，架构师点评技术团队“能力差”
bad case ：项目失败了，技术团队点评架构师“只会忽悠”
2. 跨域知识
- 如果只是一个方向能力强，顶多算技术高手
- 除了一个/几个方向的专家，对端，站点，服务，数据等多方面均要有所了解
- 对研发，测试，运维，安全均要有所了解
- 除了技术，对业务，产品，项目管理均要有所了解
3. “把问题讲清楚”是一项很重要的能力
- 懂得把复杂的事物进行抽象，简单化
- 懂得把抽象的事物进行形象，具体化
- 懂得把形象的事物落到白板上，画出来
- 懂得把白板上的事物讲出来
bad case：有些架构师，自己懂，但讲不出来，挺遗憾。
能力，沟通能力，执行力
- 光讲清楚还不够，能落地实现，才是真功夫
- 同样是技术人，沟通切忌颐指气使，发号施令
- 别把高大上的名词天天挂在嘴上，落地了什么，才是价值
画外音：最近这些名词听得多不？区块链，云计算，Saas。一定要小心，任何脱离业务的架构设计，都是耍流氓。
I didn’t say they don’t use the tools of the database; I said they shouldn’t depend upon them. The business rules should not know what specific database you are using.
How do you get the business rules to use tools without knowing about them?
You invert the dependency. You have the database depend upon the business rules. You make sure the business rules don’t depend on the database.
On the contrary, I am speaking the language of Software Architecture. This is the Dependency Inversion Principle. Low level policies should depend upon high level policies.
The principles of architecture, of course. Senders own the interfaces that the receivers must implement.
https://javax0.wordpress.com/2016/05/04/architects-dont-decide/
When you get into the position of being an architect you realize that the power is not a privilege. It is a reponsibility. The system the team develops, the architecture, the network, hardware, the operation is not a play field to satisfy your curiosity. It is a professional environment that works based on profit and lost, budget and costs, money, money, money. The decision the architect makes should not be biased by the actual person’s interest. This is, by the way, a very common mistake. “Let’s use NoSQL because that is so fancy! We have to use big data!”
The actual decision should lead to a solution that meets availability, performance, reliability, scalability, manageability and cost criteria. (Btw: the first six critera should be met, the last one should be at least met and minimized, but that is a different story.)
The actual decisions on the architecture and solutions (finally when unavoidable also about framework and database and other stuff) depends on many things. License structure, license cost, company culture/convention(tools/frameworks used/supported in the company), available developers, deadline/time to market, architecture already in place to name a few. If you consider all the constraints you have to meet you will not have too many choices. There will be compromises and finally you will end up with the only one selection that fits. That one is going to be your decision.
http://hellojava.info/?p=430业务理解和抽象能力
NB的代码能力
全面是一个架构师展现出来的最关键素质，全面会体现在三点上：
1. 在面对业务问题上，架构师脑海里是否会浮现出多种技术方案，这点其实挺重要的，否则可能就会出现明明有一个简单成熟的方案，但由于不知道而做了其他复杂不成熟的方案，所以广阔的技术视野是架构师的必备，另外架构师不可能全部擅长，在自己不擅长的点上，需要知道找哪个专业的人是靠谱的，这点也非常重要；
1. 在面对业务问题上，架构师脑海里是否会浮现出多种技术方案，这点其实挺重要的，否则可能就会出现明明有一个简单成熟的方案，但由于不知道而做了其他复杂不成熟的方案，所以广阔的技术视野是架构师的必备，另外架构师不可能全部擅长，在自己不擅长的点上，需要知道找哪个专业的人是靠谱的，这点也非常重要；
2. 在做系统设计时是否考虑到了足够多的方方面面：
例如很多系统设计容易遗漏上线环节的细节，导致在上线时发现漏掉了什么考虑，临时解决或只能重来，记得有一年我做的一个设计没有考虑到上线阶段的一个细节，导致上线的时候发现由于网段的问题完全不work，并且没有临时解决方案，只好重来，系统设计不仅仅指导研发同学怎么写代码，也包括指导其他所有相关技术同学的工作；
3. 在做系统设计时是否考虑到了未来的一些发展，尽可能不要出现未来的一点变化就导致现在白干或要花大量力气来改造的现象例如很多系统设计容易遗漏上线环节的细节，导致在上线时发现漏掉了什么考虑，临时解决或只能重来，记得有一年我做的一个设计没有考虑到上线阶段的一个细节，导致上线的时候发现由于网段的问题完全不work，并且没有临时解决方案，只好重来，系统设计不仅仅指导研发同学怎么写代码，也包括指导其他所有相关技术同学的工作；
全局
全局观通常是指在系统设计时是否考虑到了对上下游的系统的影响，毕竟通常所设计的系统不是一个孤立的系统，如果没有足够好的全局观，有可能会导致自己的系统做完上线，其他上下游系统（尤其有些连上下游是谁，怎么用的都不知道的情况下）出现问题，这种案例同样不少。
全局观通常是指在系统设计时是否考虑到了对上下游的系统的影响，毕竟通常所设计的系统不是一个孤立的系统，如果没有足够好的全局观，有可能会导致自己的系统做完上线，其他上下游系统（尤其有些连上下游是谁，怎么用的都不知道的情况下）出现问题，这种案例同样不少。
权衡
权衡同样也是架构师极度重要的能力，或者也可以认为是决策能力，技术方案的拍板是一个架构师最重要的职责。
上面说的全面是架构师在思考时开的过程，而权衡就是收的过程，收的过程结束基本就意味着技术方案的确定，同时也确定了节奏，权衡在两点上会体现的特别突出：
1. 技术方案决策原则
通常一个问题都会有多种可解决的技术方案，怎么来决策就至关重要了，而决策通常又和全面相关，大的来说通常决策的原则就是性价比和可持续发展。
性价比简单来说是方案的实现成本，这个成本要包括非常多的方面，例如有些场景可能会是用硬件解决看起来是花钱，但最终折算成本是最划算的，很多系统设计在决策性价比时都过于随意，例如一个另外常见的场景就是建设一套新系统替代旧系统，这个时候可能完全没考虑旧系统的迁移代价甚至超过了改造旧系统的代价；
可持续发展简单来说就是所选择的技术方案在公司是否可持续，例如简单的案例是公司主体的研发人员都是php，却搞一个其他语言，且只有极少人懂的（当然，这还是要看性价比，如果搞一个其他语言带来的效益超过了语言/人才体系的更换成本），又例如引入一个开源产品，有无专业团队维护这都是要考虑的关键因素。
权衡同样也是架构师极度重要的能力，或者也可以认为是决策能力，技术方案的拍板是一个架构师最重要的职责。
上面说的全面是架构师在思考时开的过程，而权衡就是收的过程，收的过程结束基本就意味着技术方案的确定，同时也确定了节奏，权衡在两点上会体现的特别突出：
1. 技术方案决策原则
通常一个问题都会有多种可解决的技术方案，怎么来决策就至关重要了，而决策通常又和全面相关，大的来说通常决策的原则就是性价比和可持续发展。
性价比简单来说是方案的实现成本，这个成本要包括非常多的方面，例如有些场景可能会是用硬件解决看起来是花钱，但最终折算成本是最划算的，很多系统设计在决策性价比时都过于随意，例如一个另外常见的场景就是建设一套新系统替代旧系统，这个时候可能完全没考虑旧系统的迁移代价甚至超过了改造旧系统的代价；
可持续发展简单来说就是所选择的技术方案在公司是否可持续，例如简单的案例是公司主体的研发人员都是php，却搞一个其他语言，且只有极少人懂的（当然，这还是要看性价比，如果搞一个其他语言带来的效益超过了语言/人才体系的更换成本），又例如引入一个开源产品，有无专业团队维护这都是要考虑的关键因素。
2. 优先级和节奏控制
经常我会问做系统设计的同学一个问题：对于这个业务场景而言，在系统设计上最需要把握的一个点是什么；这是一个关键问题，全面意味着考虑到了很多地方的问题，但通常业务需求实现都是有很强的时间要求的，因此在这个时候必须考虑清楚不同点的优先级，同时也包括技术方案在决策时也要做出取舍，有可能选了一个不是那么好的技术方案，但通过留下一些可改造的空间，为以后的重构做好铺垫，那就是很不错的，尤其技术同学有些时候比较容易陷入解决技术问题的场景去，但那个问题其实有可能不是现阶段最重要的。
经常我会问做系统设计的同学一个问题：对于这个业务场景而言，在系统设计上最需要把握的一个点是什么；这是一个关键问题，全面意味着考虑到了很多地方的问题，但通常业务需求实现都是有很强的时间要求的，因此在这个时候必须考虑清楚不同点的优先级，同时也包括技术方案在决策时也要做出取舍，有可能选了一个不是那么好的技术方案，但通过留下一些可改造的空间，为以后的重构做好铺垫，那就是很不错的，尤其技术同学有些时候比较容易陷入解决技术问题的场景去，但那个问题其实有可能不是现阶段最重要的。
其实优先级和节奏控制是我认为一个最NB的架构师的最佳体现，优先级意味着把握住了重点，可以确保在所设计的架构指导下业务实现不会出现大问题，节奏控制则意味着全面，为将来做好了铺垫。
http://h2ex.com/760
http://hellojava.info/?p=458
- 软件架构能够满足系统的品质
- 架构设计使受益人达成一致的目标
- 架构设计能够支持计划编制过程
- 架构设计对系统开发的指导性
- 架构设计能够有效地管理复杂性
- 架构设计为复用奠定了基础
- 架构设计能够降低维护费用
- 架构设计能够支持冲突分析
第1个错
在设计服务框架时，我期望服务框架对使用者完全不侵入，于是做了一个在外部放一个.xml文件来描述spring里的哪些bean发布为服务的设计，这个版本发布后，第一个小白鼠的用户勉强在用，但觉得用的很别扭，不过还是忍着用下去了，到了发布的时候，发现出现了两个问题，一是这个xml文件研发也不知道放哪好，所以到了发布的时候都不知道去哪拿这个xml文件。
这个设计的关键错误就在于在设计时没考虑过这个设计方式对研发阶段、运维阶段的影响，后来纠正这个错误的方法是去掉了这个xml文件，改为写了一个Spring FactoryBean，用户在spring的bean配置文件中配置下就可以。
因此对于一个架构师来说，设计时在全面性上要充分考虑。
在设计服务框架时，我期望服务框架对使用者完全不侵入，于是做了一个在外部放一个.xml文件来描述spring里的哪些bean发布为服务的设计，这个版本发布后，第一个小白鼠的用户勉强在用，但觉得用的很别扭，不过还是忍着用下去了，到了发布的时候，发现出现了两个问题，一是这个xml文件研发也不知道放哪好，所以到了发布的时候都不知道去哪拿这个xml文件。
这个设计的关键错误就在于在设计时没考虑过这个设计方式对研发阶段、运维阶段的影响，后来纠正这个错误的方法是去掉了这个xml文件，改为写了一个Spring FactoryBean，用户在spring的bean配置文件中配置下就可以。
因此对于一个架构师来说，设计时在全面性上要充分考虑。
第2个错
服务框架在核心应用上线时，出现了前端web应用负载高，处理线程数不够用的现象，当时处理这个故障的方式是回滚了服务框架的上线，这个故障排查了比较长的时间后，查到的原因是服务框架用的JBoss Remoting在通信时默认时间是60s，导致一些处理速度慢的请求占据了前端web应用的处理线程池。
上面这里故障的原因简单来说是分布式调用中超时时间太长的问题，但更深层次来思考，问题是犯在了设计服务框架时的技术选型，在选择JBoss-Remoting时没有充分的掌握它的运行细节，这个设计的错误导致的是后来决定放弃JBoss-Remoting，改为基于Mina重写了服务框架的通信部分，这里造成了服务框架的可用版本发布推迟了两个多月。
因此对于一个架构师来说，在技术选型上对技术细节是要有很强的掌控力的。
服务框架在核心应用上线时，出现了前端web应用负载高，处理线程数不够用的现象，当时处理这个故障的方式是回滚了服务框架的上线，这个故障排查了比较长的时间后，查到的原因是服务框架用的JBoss Remoting在通信时默认时间是60s，导致一些处理速度慢的请求占据了前端web应用的处理线程池。
上面这里故障的原因简单来说是分布式调用中超时时间太长的问题，但更深层次来思考，问题是犯在了设计服务框架时的技术选型，在选择JBoss-Remoting时没有充分的掌握它的运行细节，这个设计的错误导致的是后来决定放弃JBoss-Remoting，改为基于Mina重写了服务框架的通信部分，这里造成了服务框架的可用版本发布推迟了两个多月。
因此对于一个架构师来说，在技术选型上对技术细节是要有很强的掌控力的。
第3个错
在服务框架大概演进到第4个版本时，通信协议上需要做一些改造，突然发现一个问题是以前的通信协议上是没有版本号的，于是悲催的只能在代码上做一个很龌蹉的处理来判断是新版本还是老版本。
这个设计的错误非常明显，这个其实只要在最早设计通信协议时参考下现有的很多的通信协议就可以避免了，因此这个错误纠正也非常简单，就是参考一些经典的协议重新设计了下。
因此对于一个架构师来说，知识面的广是非常重要的，或者是在设计时对未来有一定的考虑也是非常重要的。
在服务框架大概演进到第4个版本时，通信协议上需要做一些改造，突然发现一个问题是以前的通信协议上是没有版本号的，于是悲催的只能在代码上做一个很龌蹉的处理来判断是新版本还是老版本。
这个设计的错误非常明显，这个其实只要在最早设计通信协议时参考下现有的很多的通信协议就可以避免了，因此这个错误纠正也非常简单，就是参考一些经典的协议重新设计了下。
因此对于一个架构师来说，知识面的广是非常重要的，或者是在设计时对未来有一定的考虑也是非常重要的。
说到协议，就顺带说下，当时在设计通信协议和选择序列化/反序列化上没充分考虑到将来多语言的问题，导致了后来在多语言场景非常的被动，这也是由于设计时前瞻性的缺失，所谓的前瞻性不是说一定要一开始就把未来可能会出现的问题就解掉，而是应该留下不需要整个改造就可以解掉的方法，这点对于架构师来说也是非常重要的。
第4个错
在服务框架切换为Mina的版本上线后，发布服务的应用重启时出现一个问题，就是发现重启后集群中的机器负载严重不均，排查发现是由于这个版本采用是服务的调用方会通过硬件负载均衡去建立到服务发布方的连接，而且是单个的长连接，由于是通过硬件负载均衡建连，意味着服务调用方其实看到的都是同一个地址，这也就导致了当服务发布方重启时，服务调用方重连就会集中的连到存活的机器上，连接还是长连，因此就导致了负载的不均衡现象。
这个设计的错误主要在于没有考虑生产环境中走硬件负载均衡后，这种单个长连接方式带来的问题，这个错误呢还真不太好纠正，当时临时用的一个方法是服务调用方的连接每发送了1w个请求后，就把连接自动断开重建，最终的解决方法是去掉了负载均衡设备这个中间点。
因此对于一个架构师来说，设计时的全面性要非常的好，我现在一般更多采用的方式是推演上线后的状况，一般来说在脑海里过一遍会比较容易考虑到这些问题。
在服务框架切换为Mina的版本上线后，发布服务的应用重启时出现一个问题，就是发现重启后集群中的机器负载严重不均，排查发现是由于这个版本采用是服务的调用方会通过硬件负载均衡去建立到服务发布方的连接，而且是单个的长连接，由于是通过硬件负载均衡建连，意味着服务调用方其实看到的都是同一个地址，这也就导致了当服务发布方重启时，服务调用方重连就会集中的连到存活的机器上，连接还是长连，因此就导致了负载的不均衡现象。
这个设计的错误主要在于没有考虑生产环境中走硬件负载均衡后，这种单个长连接方式带来的问题，这个错误呢还真不太好纠正，当时临时用的一个方法是服务调用方的连接每发送了1w个请求后，就把连接自动断开重建，最终的解决方法是去掉了负载均衡设备这个中间点。
因此对于一个架构师来说，设计时的全面性要非常的好，我现在一般更多采用的方式是推演上线后的状况，一般来说在脑海里过一遍会比较容易考虑到这些问题。
第5个错
服务框架在做了一年多以后，某个版本中出现了一个严重bug，然后我们就希望能通知到用了这个版本的应用紧急升级，在这个时候悲催的发现一个问题是我们压根就不知道生产环境中哪些应用和机器部署了这个版本，当时只好用一个临时的扫全网机器的方法来解决。
这个问题后来纠正的方法是在服务发布和调用者在连接我们的一个点时，顺带把用的服务框架的版本号带上，于是就可以很简单的知道全网的服务框架目前在运行的版本号了。因此对于一个架构师来说，设计时的全面性是非常重要的，推演能起到很大的帮助作用。
服务框架在做了一年多以后，某个版本中出现了一个严重bug，然后我们就希望能通知到用了这个版本的应用紧急升级，在这个时候悲催的发现一个问题是我们压根就不知道生产环境中哪些应用和机器部署了这个版本，当时只好用一个临时的扫全网机器的方法来解决。
这个问题后来纠正的方法是在服务发布和调用者在连接我们的一个点时，顺带把用的服务框架的版本号带上，于是就可以很简单的知道全网的服务框架目前在运行的版本号了。因此对于一个架构师来说，设计时的全面性是非常重要的，推演能起到很大的帮助作用。
第6个错
服务框架这种基础类型的产品，在发布时会碰到个很大的问题，就是需要通知到使用者去发布，导致了整个发布周期会相当的长，当时做了一个决定，投入资源去实现完全动态化的发布，就是不需要重启，等到做的时候才发现这完全就是个超级大坑，最终这件事在投入两个人做了接近半年后，才终于决定放弃，而且最终来看其实升级的问题也没那么大。
这个问题最大的错误在于对细节把握不力，而且决策太慢。
因此对于一个架构师来说，技术细节的掌控非常重要，同时决策力也是非常重要的。
服务框架这种基础类型的产品，在发布时会碰到个很大的问题，就是需要通知到使用者去发布，导致了整个发布周期会相当的长，当时做了一个决定，投入资源去实现完全动态化的发布，就是不需要重启，等到做的时候才发现这完全就是个超级大坑，最终这件事在投入两个人做了接近半年后，才终于决定放弃，而且最终来看其实升级的问题也没那么大。
这个问题最大的错误在于对细节把握不力，而且决策太慢。
因此对于一个架构师来说，技术细节的掌控非常重要，同时决策力也是非常重要的。
第7个错
服务发布方经常会碰到一个问题，就是一个服务里的某些方法是比较耗资源的，另外的一些可能是不太耗资源，但对业务非常重要的方法，有些场景下会出现由于耗资源的方法被请求的多了些导致不太耗资源的方法受影响，这种场景下如果要去拆成多个服务，会导致开发阶段还是挺痛苦的，因此服务框架这边决定提供一个按方法做七层路由的功能，服务的发布方可以在一个地方编写一个规则文件，这个规则文件允许按照方法将生产环境的机器划分为不同组，这样当服务调用方调用时就可以做到不同方法调用到不同的机器。
这个功能对有些场景来说用的很爽，但随着时间的演进和人员的更换，能维护那个文件的人越来越少了，也成为了问题。
这个功能到现在为止我自己其实觉得也是一直处于争议中，我也不知道到底是好还是不好…
因此对于一个架构师来说，设计时的全面性是非常重要的。
服务发布方经常会碰到一个问题，就是一个服务里的某些方法是比较耗资源的，另外的一些可能是不太耗资源，但对业务非常重要的方法，有些场景下会出现由于耗资源的方法被请求的多了些导致不太耗资源的方法受影响，这种场景下如果要去拆成多个服务，会导致开发阶段还是挺痛苦的，因此服务框架这边决定提供一个按方法做七层路由的功能，服务的发布方可以在一个地方编写一个规则文件，这个规则文件允许按照方法将生产环境的机器划分为不同组，这样当服务调用方调用时就可以做到不同方法调用到不同的机器。
这个功能对有些场景来说用的很爽，但随着时间的演进和人员的更换，能维护那个文件的人越来越少了，也成为了问题。
这个功能到现在为止我自己其实觉得也是一直处于争议中，我也不知道到底是好还是不好…
因此对于一个架构师来说，设计时的全面性是非常重要的。
第8个错
服务框架在用的越来越广后，碰到了一个比较突出的问题，服务框架依赖的jar版本和应用依赖的jar版本冲突，服务框架作为一个通用技术产品，基本上没办法为了一个应用改变服务框架自己依赖的jar版本，这个问题到底怎么去解，当时思考了比较久。
可能是由于我以前OSGi这块背景的原因，在设计上我做了一个决定，引入OSGi，将服务框架的一堆jar处于一个独立的classloader，和应用本身的分开，这样就可以避免掉jar冲突的问题，在我做了引入OSGi这个决定后，团队的1个资深的同学就去做了，结果是折腾了近两个月整个匹配OSGi的maven开发环境都没完全搭好，后来我自己决定进去搞这件事，即使是我对OSGi比较熟，也折腾了差不多1个多月才把整个开发的环境，工程的结构，以及之前的代码基本迁移为OSGi结构，这件事当时折腾好上线后，效果看起来是不错的，达到了预期。
但这件事后来随着加入服务框架的新的研发人员越来越多，发现多数的新人都在学习OSGi模式的开发这件事上投入了不少的时间，就是比较难适应，所以后来有其他业务问是不是要引入OSGi的时候，我基本都会建议不要引入，主要的原因是OSGi模式对大家熟悉的开发模式、排查问题的冲击，除非是明确需要classloader隔离、动态化这两个点。
让我重新做一个决策的话，我会去掉对OSGi的引入，自己做一个简单的classloader隔离策略来解决jar版本冲突的问题，保持大家都很熟悉的开发模式。
服务框架在用的越来越广后，碰到了一个比较突出的问题，服务框架依赖的jar版本和应用依赖的jar版本冲突，服务框架作为一个通用技术产品，基本上没办法为了一个应用改变服务框架自己依赖的jar版本，这个问题到底怎么去解，当时思考了比较久。
可能是由于我以前OSGi这块背景的原因，在设计上我做了一个决定，引入OSGi，将服务框架的一堆jar处于一个独立的classloader，和应用本身的分开，这样就可以避免掉jar冲突的问题，在我做了引入OSGi这个决定后，团队的1个资深的同学就去做了，结果是折腾了近两个月整个匹配OSGi的maven开发环境都没完全搭好，后来我自己决定进去搞这件事，即使是我对OSGi比较熟，也折腾了差不多1个多月才把整个开发的环境，工程的结构，以及之前的代码基本迁移为OSGi结构，这件事当时折腾好上线后，效果看起来是不错的，达到了预期。
但这件事后来随着加入服务框架的新的研发人员越来越多，发现多数的新人都在学习OSGi模式的开发这件事上投入了不少的时间，就是比较难适应，所以后来有其他业务问是不是要引入OSGi的时候，我基本都会建议不要引入，主要的原因是OSGi模式对大家熟悉的开发模式、排查问题的冲击，除非是明确需要classloader隔离、动态化这两个点。
让我重新做一个决策的话，我会去掉对OSGi的引入，自己做一个简单的classloader隔离策略来解决jar版本冲突的问题，保持大家都很熟悉的开发模式。
第9个错
服务框架在用的非常广了后，团队经常会被一个问题困扰和折腾，就是业务经常会碰到调用服务出错或超时的现象，这种情况通常会让服务框架这边的研发来帮助排查，这个现象之所以查起来会比较复杂，是因为服务调用通常是多层的关系，并不是简单的A–>B的问题，很多时候都会出现A–>B–>C–>D或者更多层的调用，超时或者出错都有可能是在其中某个环节，因此排查起来非常麻烦。
在这个问题越来越麻烦后，这个时候才想起在09年左右团队里有同学看过G家的一篇叫dapper的论文，并且做了一个类似的东西，只是当时上线后我们一直想不明白这东西拿来做什么，到了排查问题这个暴露的越来越严重后，终于逐渐想起这东西貌似可以对排查问题会产生很大的帮助。
到了这个阶段才开始做这件事后，碰到的主要不是技术问题，而是怎么把新版本升级上去的问题，这个折腾了挺长时间，然后上线后又发现了一个新的问题是，即使服务框架具备了Trace能力，但服务里又会调外部的例如数据库、缓存等，那些地方如果有问题也会看不到，排查起来还是麻烦，于是这件事要真正展现效果就必须让Trace完全贯穿所有系统，为了做成这件事，N个团队付出了好几年的代价。
因此对于一个架构师来说，设计时的全面性、前瞻性非常重要，例如Trace这个的重要性，如果在最初就考虑到，那么在一开始就可以留好口子埋好伏笔，后面再要做完整就不会太复杂。
在这个问题越来越麻烦后，这个时候才想起在09年左右团队里有同学看过G家的一篇叫dapper的论文，并且做了一个类似的东西，只是当时上线后我们一直想不明白这东西拿来做什么，到了排查问题这个暴露的越来越严重后，终于逐渐想起这东西貌似可以对排查问题会产生很大的帮助。
到了这个阶段才开始做这件事后，碰到的主要不是技术问题，而是怎么把新版本升级上去的问题，这个折腾了挺长时间，然后上线后又发现了一个新的问题是，即使服务框架具备了Trace能力，但服务里又会调外部的例如数据库、缓存等，那些地方如果有问题也会看不到，排查起来还是麻烦，于是这件事要真正展现效果就必须让Trace完全贯穿所有系统，为了做成这件事，N个团队付出了好几年的代价。
因此对于一个架构师来说，设计时的全面性、前瞻性非常重要，例如Trace这个的重要性，如果在最初就考虑到，那么在一开始就可以留好口子埋好伏笔，后面再要做完整就不会太复杂。
第10个错
服务的发布方有些时候会碰到一个现象是，服务还没完全ready，就被调用了；还有第二个现象是服务发布方出现问题时，要保留现场排查问题，但服务又一直在被调用，这种情况下就没有办法很好的完全保留现场来慢慢排查问题了。
这两个现象会出现的原因是服务框架的设计是通过启动后和某个中心建立连接，心跳成功后其他调用方就可以调用到，心跳失败后就不会被调到，这样看起来很自动化，但事实上会导致的另外一个问题是外部控制上下线这件事的能力就很弱。这个设计的错误主要还是在设计时考虑的不够全面。
服务的发布方有些时候会碰到一个现象是，服务还没完全ready，就被调用了；还有第二个现象是服务发布方出现问题时，要保留现场排查问题，但服务又一直在被调用，这种情况下就没有办法很好的完全保留现场来慢慢排查问题了。
这两个现象会出现的原因是服务框架的设计是通过启动后和某个中心建立连接，心跳成功后其他调用方就可以调用到，心跳失败后就不会被调到，这样看起来很自动化，但事实上会导致的另外一个问题是外部控制上下线这件事的能力就很弱。这个设计的错误主要还是在设计时考虑的不够全面。
第11个错
在某年我和几个小伙伴决定改变当时用xen的模式，换成用一种轻量级的“虚拟机”方式来做，从而提升单机跑的应用数量的密度，在做这件事时，我们决定自己做一个轻量级的类虚拟机的方案，当时决定的做法是在一个机器上直接跑进程，然后碰到一堆的问题，例如从运维体系上来讲，希望ssh到“机器”、独立的ip、看到自己的系统指标等等，为了解决这些问题，用了N多的黑科技，搞得很悲催，更悲催的是当时觉得这个问题不多，于是用一些机器跑了这个模式，结果最后发现这里面要黑科技解决的问题实在太多了，后来突然有个小伙伴提出我们试用lxc吧，才发现我们之前用黑科技解的很多问题都没了，哎，然后就是决定切换到这个模式，结果就是线上的那堆机器重来。
这个设计的主要错误在于知识面不够广，导致做了个不正确的决定，而且推倒重来。因此对于一个架构师来说，知识面的广非常重要，在技术选型这点上非常明显。
这个设计的主要错误在于知识面不够广，导致做了个不正确的决定，而且推倒重来。因此对于一个架构师来说，知识面的广非常重要，在技术选型这点上非常明显。
第12个错
还是上面这个技术产品，这个东西有一个需求是磁盘空间的限额，并且要支持磁盘空间一定程度的超卖，当时的做法是用image的方式来占磁盘空间限额，这个方式跑了一段时间觉得没什么问题，于是就更大程度的铺开了，但铺开跑了一段时间后，出现了一个问题，就是经常出现物理机磁盘空间不足的报警，而且删掉了lxc容器里的文件也还是不行，因为image方式只要占用了就会一直占着这个大小，只会扩大不会缩小。
当时对这个问题极度的头疼，只能是删掉文件后，重建image，但这个会有个要求是物理机上有足够的空间，即使有足够的空间，这个操作也是很折腾人的，因为得先停掉容器，cp文件到新创建的容器，这个如果东西多的话，还是要耗掉一定时间的。
后来觉得这个模式实在是没法玩，于是寻找新的解决方法，来满足磁盘空间限额，允许超卖的这两需求，最后我们也是折腾了比较长一段时间后终于找到了更靠谱的解决方案。
这个设计的主要错误还是在选择技术方案时没考虑清楚，对细节掌握不够，考虑的面不够全，导致了后面为了换掉image这个方案，用了极大的代价，我印象中是一堆的人熬了多次通宵来解决。
还是上面这个技术产品，这个东西有一个需求是磁盘空间的限额，并且要支持磁盘空间一定程度的超卖，当时的做法是用image的方式来占磁盘空间限额，这个方式跑了一段时间觉得没什么问题，于是就更大程度的铺开了，但铺开跑了一段时间后，出现了一个问题，就是经常出现物理机磁盘空间不足的报警，而且删掉了lxc容器里的文件也还是不行，因为image方式只要占用了就会一直占着这个大小，只会扩大不会缩小。
当时对这个问题极度的头疼，只能是删掉文件后，重建image，但这个会有个要求是物理机上有足够的空间，即使有足够的空间，这个操作也是很折腾人的，因为得先停掉容器，cp文件到新创建的容器，这个如果东西多的话，还是要耗掉一定时间的。
后来觉得这个模式实在是没法玩，于是寻找新的解决方法，来满足磁盘空间限额，允许超卖的这两需求，最后我们也是折腾了比较长一段时间后终于找到了更靠谱的解决方案。
这个设计的主要错误还是在选择技术方案时没考虑清楚，对细节掌握不够，考虑的面不够全，导致了后面为了换掉image这个方案，用了极大的代价，我印象中是一堆的人熬了多次通宵来解决。
第13个错
仍然是上面的这个技术产品，在运行的过程中，突然碰到了一个虚拟机中线程数创建太多，导致其他的虚拟机也创建不了线程的现象（不是因为物理资源不够的问题），排查发现是由于尽管lxc支持各个容器里跑相同名字的账号，但相同名字的账号的uid是相同的，而max processes是限制在UID上的，所以当一个虚拟机创建的线程数超过时，就同样影响到了其他相同账号的容器。
这个问题我觉得一定程度也可以算是设计问题，设计的时候确实由于对细节掌握的不够，考虑的不全导致忽略了这个点。
这个问题我觉得一定程度也可以算是设计问题，设计的时候确实由于对细节掌握的不够，考虑的不全导致忽略了这个点。
第14个错
在三年前做一个非常大的项目时，项目即将到上线时间时，突然发现一个问题是，有一个关键的点遗漏掉了，只好赶紧临时讨论方案决定怎么做，这个的改动动作是非常大的，于是项目的上线时间只能推迟，我记得那个时候紧急周末加班等搞这件事，最后带着比较高的风险上了。
这个问题主要原因是在做整体设计时遗漏掉了这个关键点的考虑，当时倒不是完全忽略了这个点，而是在技术细节上判断错误，导致以为不太要做改动。
因此对于一个架构师来说，对技术细节的掌控是非常重要的，这里要注意的是，其实不代表架构师自己要完全什么都很懂，但架构师应该清楚在某个点上靠谱的人是谁。
这个问题主要原因是在做整体设计时遗漏掉了这个关键点的考虑，当时倒不是完全忽略了这个点，而是在技术细节上判断错误，导致以为不太要做改动。
因此对于一个架构师来说，对技术细节的掌控是非常重要的，这里要注意的是，其实不代表架构师自己要完全什么都很懂，但架构师应该清楚在某个点上靠谱的人是谁。
