1.什么是系统架构设计
系统架构设计描述了在应用系统的内部，如何根据业务、技术、组织、灵活性、可扩展性以及可维护性等多种因素，将应用系统划分成不同的部分，并使这些部分彼此之间相互分工、相互协作，从而为用户提供某种特定价值的方式。
2.什么是单块架构应用
随着面向对象分析、设计模式、企业架构模式等方法论的深入人心。从功能实现、代码组织的角度分析，系统中不同职责的部分逐渐划分到了如下三个层次： 表示层：聚焦数据显示和用户交互 业务逻辑层：聚焦业务逻辑处理 数据访问层：聚焦数据的储存和访问 三层架构的出现，不仅解决了系统间调用的复杂、职责不清的问题，更有效地降低了层与层之间的依赖关系，成为软件架构的经典模式之一。虽然三层架构将系统在逻辑上分成了三层，但它并不是物理上的分层。也就是说对于不同层的代码而已，经历编译、打包、部署后，所有的代码最终还是运行在同一个进程中。 对于这种功能集中、代码中心化、一个发布包、部署后运行在同一个进程中应用程序，通常称之为单块架构应用。他们存在的形态一般是WAR或者EAR包。 随着业务的不断扩大，需求功能的持续增加，单块架构已经很难满足业务快速变化的需要。一方面，代码的可维护性、可扩展性、灵活性在降低；另一方面，系统的修改成本、构建以及维护成本在显著增加。因此，单块架构应用的改造与重构势在必行。
3.单块结构的优势
易于开发 容易理解而且人所熟知，现有的集成开发工具比较适合单块架构的应用程序，Eclipse、IDEA等，方便开发人员开发、运行、调试等。 易于测试 所有功能都在运行在一个进程中，一旦启动进程，可以立即开始系统或者功能测试。 易于部署 所有功能最终都会打成一个包，复制该软件包到服务器相应的位置即可。 易于水平伸缩
4.单块架构面临的挑战
1）维护成本增加 随着功能越来越多，团队越来越大，相应的沟通、管理、人员成本也必然会显著增加。程序功能增多，出现缺陷时，有可能引起缺陷的原因就会比较多，这样会导致分析、定位、修复的缺陷成本增高。从而会导致“修复越多，缺陷越多”的恶心循环，维护成本高居不下。 2）持续交付周期长 随着应用程序的功能越来越多，代码越来越复杂，构建和部署的时间也会相应增加。流水线的反馈周期变长，单位时间内构建的效率变低。 3）新人培训周期长 （功能多）对于新加入的团队成员而言，了解行业背景、熟悉应用程序业务、配置环境等看似简单的任务，将花费越来越长的时间。 4）技术选型成本高 构建全功能团队难
5.互联网时代产品特点
创新成本低、需求变化快、用户群体庞大，他和几年前我们熟悉的单块架构应用有着本质的不同。随着市场变化、用户需求变化加快、用户访问量增加，单块架构应用的维护、人员培养、缺陷修复、技术架构成本以及系统扩展等相应增加，因此单块架构曾经的优势已逐渐无法适应互联网时代的快速变化，面临越来越多的挑战。
6.什么是微服务架构
微服务架构师一种架构模式，它提倡将单一应用程序划分成为一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常基于HTTP的RESTful API）。
7.静态类型语言
主要优点在于其结构规范，存在编译期的语法检查、便于调试、类型安全性高，通常继承关系简洁明了；其缺点是为此需要写更多的类型相关代码。因此代码量相对稍多，典型代表有Java，C++等。
8.动态类型语言
动态语言，其灵活性较高，运行时可以改变内存结构，无类型检查，无需写较多的类型相关的代码，但缺点是不方便调试，无编译期检查，多个体的能力要求较高。典型代表：JavaScript、Ruby或者Python等。
9.轻量级通信
服务之间应通过轻量级的通信机制，实现彼此间的互通互联，互相协作。所谓轻量级通信机制，通常指语言无关平台无关的交互方式。对于轻量级通信的协议而言，通常基于HTTP，能让服务间的通信变得标准化并且无状态化。目前，大家所熟悉的REST是实现服务之间互相协作的轻量级通信机制之一。 对于微服务而言，通过使用语言无关、平台无关的轻量级通信机制，使服务与服务之间的协作变得更加标准化，也就意味着在保持服务外部通信机制轻量级的情况下，团队可以选择更合适的语言、工具或者平台来开发服务本身。
10.独立性
独立性指在应用的交付过程中，开发、测试以及部署的独立。 在传统的单块架构应用中，所有功能都存在于同一个代码库中，当修改了代码库的中某一个功能，很容易出现功能之间相互影响的情况。尤其是随着代码量、功能的不断增加，风险也会逐渐增加。换句话说，功能的开发不具备独立性。 除此之外，当多个特性被不同小组实现完毕。需要经过集成，经过回归测试，团队才有足够的信心，保证功能相互配合、正常工作并且互不影响。因此测试过程也不具备一个独立的过程。 在微服务架构中，每个服务都是一个独立的业务单元，当对某个服务进行改变时，对其他的无法不会产生影响。换句话说，服务与服务之间是独立的。 对于每个服务，都有独立的代码库。当对当前服务的代码进行修改后，并不会影响其他服务。从代码库的层面而言，服务与服务是隔离的。 对于每个服务，都有独立的测试机制，并不必担心破坏其他功能而需要建立大范围的回归测试。也就是说，从测试的角度而言，服务与服务之间是松耦合的。 综上所述，微服务架构其实是单一的应用程序划分成为一组小的服务，每个服务都是具有业务属性的独立单元，同时能够被独立开发、独立运行、独立测试以及独立部署。
11.容器虚拟化技术
Docker是 一个开源的应用容器引擎，允许开发者将他们的应用以及依赖包打包到一个可移植的容器中，然后发布到任何装有Docker的Linux机器上。 Docker的优势主要体现在： 更快速地交付和部署。开发者可以使用一个标准的镜像来构建镜像，开发完成之后，运维 人员可以直接使用这个镜像来部署。 更轻松地迁移和扩展，Docker容器可以在任意平台上运行，包括物理机、虚拟机、公有云、私有云等。这种兼容性可以低成本地将应用程序从一个平台直接迁移到另一个。 更简单地管理。使用Docker，所有镜像的修改都能以增量的方式被分发和更新，从而实现自动化并且高效的管理。 Docker的出现，有效地解决了微服务架构下，服务粒度细、服务数量多所导致的开发环境搭建、部署以及运维成本高的问题。如果说敏捷、精益、持续交付以及DevOps是微服务诞生的催化剂，那Docker的出现，则有效解决了微服务的环境搭建、部署以及运维成本高的问题。
12.微服务与SOA区别
13.微服务的本质
服务作为组件 围绕业务组织团队 关注产品而非项目 技术多样性 业务数据独立 基础设施自动化
14.分布式系统的复杂度
性能 同传统的单块架构相比，分布式系统由于组件与组件的调用是跨进程、跨网络的调用，因此必然要考虑网络延迟以及带宽的影响。 可靠性 在分布式系统中，由于网络、带块、节点自身的可靠性等因素，任何一次组件间的远程调用都有可能失败。如何提高系统的可靠性，降低由于网络、组件等引起的单点故障率，也增加了系统构建的挑战。 异步 对于跨网络的调用，需要考虑异步的通信机制。同步通信实现简单，但是会造成阻塞。 数据一致性 在分布式系统中，为了保证数据的一致性，通常我们会考虑使用分布式事务管理。但由于分布式事务管理需要跨多个节点来保证数据的瞬时一致性，因此比起传统的单块架构的事务，成本要高得多。
15.运维成本
配置 部署 监控与告警 日志收集 相比传统的单块架构应用，微服务将系统分成多个独立的部分，每个部分都是可以独立部署的业务单元。
16.微服务小结
微服务架构将一个应用拆分成多个独立的、具有业务属性的服务，每个服务运行在不同的进程中，服务与服务之间通过轻量级的通信机制相互协作、配合，从而为终端用户提供业务价值。微服务架构强调的是一种独立开发、独立测试、独立部署、独立运行的高度自治的架构模式，也是一种更灵活、开发、松散的演进式架构。
17.什么是持续交付
对于任何一个可交付的软件来说，必然要经历分析、设计、开发、测试、构建、部署、运维的过程。而从加粗样式持续交付的角度来分析，对于任何一个可部署的独立单元，它都应该有一套独立的交付机制，来有效支撑其开发、测试、构建、部署与运维的整个过程。 从技术上来讲，持续交付是软件系统的构建、部署、测试、审核、发布过程的一种自动化实现，而其中的核心则是部署流水线。
18.持续交付的核心
持续交付的核心：小、频、快 小批量价值流动 频繁可发布 快速反馈
19.同步通信和异步通信
同步通信，是指客户端发出请求后，在服务端处理未结束前，客户端一直处于等待状态，直到最终获得终端的响应。 异步通信，是指客户端发出请求后，服务端或者第三方组件会先接受消息并应答，然后在合适的时间对请求进行处理。不过在处理的过程中，客户端不需要一直处于等待状态。
20.什么是序列化？反序列化
Java序列化是指对象转换为字节序列的过程，而反序列化是将字节序列转换为目标对象的过程。 seriallization序列化：将对象转化为便于传输的格式，常见的序列化格式：二进制字节数组，json字符串，xml字符串。 deseriallization反序列化：将序列化的数据恢复为对象的过程。
eg:后期会继续补充，各位看官如果有其他问题可以私聊讨论
