成为架构师，是许多程序员的职业梦想。然而其中只有少数有着丰厚编码积累、超强自驱力和独到思维的程序员才能最终成为架构师。其实，日常工作中小到某个功能的开发，大到整个业务系统的设计，都可以看到架构设计的影子。
所谓架构，是为了解决软件系统的某个复杂度带来的具体问题，将模块和组件以某种方式有机组合，基于某个具体的框架实现后的一种落地方案。而讨论架构时，往往只讨论到系统与子系统这个顶层的架构。
可见，要进行架构选型，首先应该知道自己要解决的业务和系统复杂点在哪里，是作为秒杀系统有瞬间高并发，还是作为金融科技系统有极高的数据一致性和可用性要求等。
一般来说，系统的复杂度来源有以下几个方面：
高性能
如果业务的访问频率或实时性要求较高，则会对系统提出高性能的要求。
如果是单机系统，需要利用多进程、多线程技术。
如果是集群系统，则还涉及任务拆分、分配与调度，多机器状态管理，机器间通信，当单机性能达到瓶颈后，即使继续加机器也无法继续提升性能，还是要针对单个子任务进行性能提升。
高可用
如果业务的可用性要求较高，也会带来高可用方面的复杂度。高可用又分为计算高可用和存储高可用。
针对计算高可用，可以采用主备（冷备、温备、热备）、多主的方式来冗余计算能力，但会增加成本、可维护性方面的复杂度。
针对存储高可用，同样是增加机器来冗余，但这也会带来多机器导致的数据不一致问题，如遇到延迟、中断、故障等情况。难点在于怎么减少数据不一致对业务的影响。
既然主要解决思路是增加机器来做冗余，那么就涉及到了状态决策的问题。即如果判断当前主机的状态是正常还是异常，以及异常了要如何采取行动（比如切换哪台做主机）。
对主机状态的判断，多采用机器信息采集或请求响应情况分析等手段，但又会产生采集信息这一条通信链路本身是否正常的问题。事实上，状态决策本质上不可能做到完全正确。
而对于决策方式，有以下几种方式：
独裁式：存在一个独立的决策主体来收集信息并决定主机，这样的策略不会混乱，但这个主体本身存在单点问题。
协商式：两台备机通过事先指定的规则来协商决策出主机，规则虽然简单方便，但是如果两台备机之间的协商链路中断了，决策起来就会很困难，比如有网络延迟且机器未故障、网络中断且机器未故障、网络中断其机器已故障，多种情况需要处理。
民主式：如果有多台备机，可以使用选举算法来投票出主机，比如 Paxos 就是一种选举算法，这种算法大多数都采取多数取胜的策略，算法本身较为复杂，且如果像协商式一样出现连接中断，就会脑裂，不同部分会各自决策出不同结果，需要规避。
