架构师笔试题
微服务架构相比单块式（烟囱式）架构有什么优缺点？（50分）
单块架构应用的优势
*易于开发对单块架构的应用程序而言，开发方式相对较简单。首先从概念上，现有的大部分工具、应用服务器、框架都是这类单块架构应用程序，容易理解而且为人所熟知。如果从实践角度出发，现有的集成开发工具比较适合单块架构的应用程序，像NetBeans、Eclipse、IDEA等，它们都能够有效加载并配置整个应用程序的依赖，方便开发人员开发、运行、调试等。
*易于测试单块架构应用程序也非常容易被测试，因为所有的功能都运行在一个进程中，启动集成开发环境或者将发布包部署到某一环境，一旦启动该进程，就可以立即开始系统测试或者功能测试。
*易于部署对单块架构的应用程序而言，部署也比较容易。实际上，由于所有的功能最终都会打成一个包，因此只需复制该软件包到服务器相应的位置即可。当然，部署的方式可以有很多种，最简单的可以使用SCP远程拷贝到指定的目录下，当然也可以使用某些自动化的工具来完成。
*易于水平伸缩对单块架构的应用程序而言，水平伸缩也比较容易。实际上，由于所有的功能最终都会打成一个包，且只能运行在一个进程中，因此单块架构的水平伸缩，更确切的理解其实是克隆，即新建一个服务器节点，配置好该节点的运行环境，复制软件包到相应的位置，运行改应用程序。当然，必须要确保负载均衡器能采取某种分发策略，有效的将请求分发到新创建的节点。
单块架构面临的挑战
随着最近几年互联网行业的迅猛发展，随着公司或者组织业务的不断扩张，需求不断的增加以及用户量的不断增加，单块架构的优势已逐渐无法适应互联网时代的快速变化，面临着越来越多的挑战。譬如说，一方面，随着业务的扩大，如何为用户提供可靠的服务，如何有效处理用户增多后导致并发请求数增多，导致的响应慢的问题，以及如何有效解决用户增多后带来的大数据量的问题等。另外一方面，随着公司或者组织业务的不断扩张，需求不断的增加，越来越多的人加入开发团队，代码库也在急剧膨胀。在这种情况下，单块架构的可维护性、灵活性在降低，而测试成本、构建成本以及维护成本却在显著增加。
1.维护成本增加
随着应用程序的功能越来越多，团队越来越大，相应的沟通成本、管理成本、人员协调成本必然会显著增加。譬如说，对于使用Java编写的中型应用而言，当代码量为几万行时，可能只需要几人左右的团队维护。当代码量上升到几十万行级别时，可能需要几十人甚至是上百人的团队。
另外，随着应用程序功能的增多，当出现缺陷时，有可能引起缺陷的原因组合就会比较多，这也会导致分析缺陷、定位缺陷、修复缺陷的成本相应增高，也就意味着缺陷的平均修复周期可能会花费更长时间。
另外，随着代码量的增大，在开发人员对全局功能缺乏深度理解的情况下，修复一个缺陷，还有可能引入其他的缺陷，在自动化测试机制不完善的情况下，很可能导致该过程陷入“修复越多，缺陷越多”的恶性循环。
2.持续交付周期长
随着应用程序的功能越来越多，代码越来越复杂，构建和部署时间也会相应的增长。在现有部署流水线稳定工作的情况下，对单块架构应用程序做任何细微的修改以及代码提交，都会触发部署流水线，对整个应用程序进行代码编译、运行单元测试、代码检查、构建并生成部署包、验证功能等，这也就意味着流水线的反馈周期变长，单位时间内构建的效率变低了。
另一方面，团队人员的增多，部署流水线运行的时间增加，开发人员能够提交代码的时间窗口就相应减少，（因为流水线运行的过程中，是禁止提交代码的），可能出现长时间等待代码提交，却无法提交的情况，极大破坏了团队的灵活性并降低了团队工作效率。
3.新人培养周期长
随着应用程序的功能越来越多，代码变得越来越复杂的同时，对于新加入团队的成员而言，了解行业背景、熟悉应用程序业务、配置本地开发环境，这些看似简单的任务，将会花费更长的时间。
4.技术选型成本高
传统的单块架构系统倾向采用统一的技术平台或方案来解决所有问题。通常，技术栈的决策是在团队开发之前经过架构师、技术经理慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统，而且要使用类似的工具。随着应用程序的复杂性逐渐增加以及功能越来越多，如果团队希望尝试引入新的框架、技术，或者对现有技术栈升级，通常会面临不小的风险。
另一方面，互联网行业不仅市场变化快，而且技术变化也快。譬如，短短几年几年时间，光前端JavaScript的框架，就出现了好几十个。类似的，后端的框架、工具等也是层出不穷。因此，对单块架构的应用而言，初始的技术选型严重限制了其将来采用不同语言或框架的能力。如果想尝试新的编程语言或者框架，没有完备的功能测试集，很难平滑的完成替换，而且系统规模越大，风险越高。
5.可伸缩性差
如果应用程序的所有功能代码都运行在同一个服务器上，将会导致应用程序的扩展非常困难。如果迫切的需要扩展，那么垂直扩展可能是最容易的（钱不是问题）。在大多数情况下，如果舍得砸钱上IBM的服务器、Oracle的数据库或者来自EMC的存储设备，不用改变一行代码，整个世界都变好了。不幸的是，伴随着业务的增长，数据的增长，垂直扩展会变得越来越吃力，成本越来越高。这也是为什么在业很多公司开始尝试使用开源，放弃这些昂贵的IOE产品的原因。
当考虑水平扩展时，通常的做法是建立一个集群，通过在集群中不断的添加新节点，然后借助前端的负载均衡器，将用户的请求按照某种算法，譬如轮转法、散列法或者最小连接法等合理的将请求分配到不同的节点上。但是，由于所有程序代码都运行在服务器上的同一个进程中，会导致应用程序的水平扩展成本非常高。譬如说，如果应用程序某部分的功能是内存密集型的，如需要缓存大量数据，而另外一部分功能是CPU密集型的，如需要进行大量的运算，那么每次实施水平扩展，运行该应用的服务器都必须有足够的内存和强劲的CPU来满足需求。因此，鉴于每个服务器都要提供该应用系统所需要的各种资源，基础设施的整体花费可能会非常高。当然，如果某些节点保持状态，如用户登陆后的会话信息等，更增加了水平扩展的难度。
6.构建全功能团队难
最后，非常微妙的是，随着应用程序的功能越来越多，代码变得越来越复杂，其应用程序的复杂结构也会逐渐映射到研发团队的结构上。康威定律指出：一个组织的设计成果，其结构往往对应于这个组织中的沟通结构。单块架构的开发模式在分工时往往以技能为单位，比如UX团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。譬如说，用户体验工程师（UX）更专注负责用户接口部分，业务层开发者则负责建立服务器后端的业务逻辑，数据库工程师和DBA们更