这是我参与「第三届青训营 -后端场」笔记创作活动的的第3篇笔记
1.什么是架构
架构的定义：是有关软件整体结构与组件的抽象描述，用户指导软件系统各个方面的设计.当实现一个软件有很多种方法的时候，架构能给我们一个很好的指导选择方法的作用。
架构的重要性:架构就好像地基，地基坚实了，大厦才能盖得高盖得好.换个方式理解，好的架构能使我们站在巨人肩膀上，看的高看得远，避免之后的一些问题，出现了问题也能很快解决。
根据我们关注的角度不同，可以将架构分成三种： 1.逻辑架构： 软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件等等。系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。 2.物理架构： 软件元件是怎样放到硬件上的。比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器。主机等等。如图是一个物理架构的例子 3.系统架构： 系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
单机
单机架构也是最基本的架构，单机服务的形态一般只适合出现在预研和初创阶段，如果业务有发展和迭代诉求，就应该快速做架构迭代。单机服务模式除了简单之外没有任何有点，而它的问题就在于在系统运维的时候需要停机维护。
集群架构
单机处理到达瓶颈的时候，工程师就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍。
分布式架构
从单机结构到集群结构，业务代码基本不需要作任何修改，工程师要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。但是，从集群结构演进到微服务结构，之前的代码就需要发生较大的改动。所以对于新系统，系统设计之初就采用微服务架构，这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要架构师深思熟虑、权衡投入产出比。
分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统。在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在 web 容器中，它们之间通过 RPC 方式通信。
举个例子，假设需要开发一个在线商城。按照微服务的思想，需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过 RPC 方式调用。
分布式架构优点
系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。 系统之间的耦合度降低，从而系统更易于扩展，可以针对性地扩展某些服务。假设商城要搞大促，下单量可能会大大提升，因此可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。 服务的复用性更高。比如，将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。
后端架构实战
在课程最后，对一个模拟的场景问题进行了讨论，就是对师傅们的工作分配问题进行讨论。 根据问题，提出了自适应静态权重，也就是在每个容器注册的时候确定不同的权重，这种方式复杂度低，完全符合分布式，微服务的中间件适应无成本。缺点就是无法做到运行时自适应。
总结
对于不同的架构有各自的优缺点，当我们使用或者设计架构时候应该根据需求来确定选用哪个架构或者如何设计。
在进行架构设计时应当做到： 需求先行、业界调研、确定技术选型、考虑可能的异常情况。
