关于系统架构的宏观介绍（由学习微服务架构引发的思考）

一、什么是系统架构（软件架构）

1. 软件架构：像学写文章一样，在学会用字、词、句之后，就应上升到段落，就应上升到文章的“布局谋篇”，这就是架构。通常来讲，软件架构设计就是软件系统系统的“布局谋篇”。
2. 软件架构与系统架构：（个人理解）软件是系统的一部分，所以软件架构也是系统架构的一部分，但是由于大多数情况下，软件是系统的主体，且设计软件架构时也要综合考虑硬件特性和网络特性，所以软件架构与系统架构之间的区别其实不大。

二、架构风格分类

  讨论架构风格时要考虑最关键的四个要素，即提供一个词汇表、定义一套配置规则、定义一套语义解释原则和定义对基于这种风格的系统所进行的分析。Carlan和Shaw根据此框架给出了通用架构风格的分类（后面是具体的架构风格）：

  1. 数据流风格：批处理序列；管道/过滤器
      最简单的架构，所有的数据按照流的形式在执行过程中前进，不存在结构的反复和重构。
  2. 调用/返回风格：主程序/子程序；面向对象风格；层次结构
      在系统中采用了调用与返回机制，实际上是一种分而治之的策略，即将一个复杂的大系统分解为一些子系统，以便降低复杂度，并且增加可修改性。
  3. 独立构件风格：进程通信；事件系统
      独立构件风格主要强调系统中的每个构件都是相对独立的个体，他们之间不直接通信，以降低耦合度，提升灵活性。
  4. 虚拟机风格：解释器；基于规则的系统
      认为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言。
  5. 仓库风格：数据库系统；超文本系统；黑板系统

三、层次结构（常见所以讲一下）

  层次结构中，每一层为上层服务，并作为下层的客户。但并不是每个系统都适合分层的模式，很难找到一个合适的、正确的层次抽象方法。
  典型的层次系统架构风格：

  1. 二层及三层C/S架构风格
  2. B/S架构风格
  3. MVC架构风格
    MVC（Model View Controller），是分层架构的一种。
    Model是对应用状态和业务功能的封装，接受Controller的请求并完成相应的业务处理，在改变状态的时候向View发出相应的通知。
    View实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。
    View捕捉到用户的交互操作后会直接转发给Controller，后者完成相应的UI逻辑。如果需要涉及业务功能的调用，Controller会直接调用Model。在完成UI处理后，Controller会根据需要控制原View或者创建新的View对用户操作予以响应。
  4. MVP架构风格
    MVP的全称为Model-View-Presenter，Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理。MVP是从讲点的MVC演变而来的，他们的基本思想由相同的地方：Controller/presenter负责逻辑的处理，Model提供数据，View负责显示。当然MVP与MVC也有一些显著的区别，MVC模式中元素之间“混乱”的交互主要体现在允许View和Model直接进行“交流”，这在MVP模式中是不允许的。

四、面向服务的架构SOA（流行所以讲一下）

（一）SOA概述

  迄今为止，对于面向服务的架构（Service-Oriented Architecture,SOA）还没有一个公认的定义。一般认为，SOA是一种程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。

  • SOA是面向对象模型的一种替代，SOA是基于对象的，但是作为一个整体，它却不是面向对象的。
  • 所有的功能都被定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。
  • 与SOA紧密相关的技术主要有UDDI（统一描述、发现和集成）、WSDL（服务描述语言）、SOAP（简单对象访问协议）、REST（表述性状态转移）等，而这些技术都是以XML为基础而发展起来的。

（二）SOA的实现方法

  1. Web Service
  2. 服务注册表
    在SOA设计时使用，也具有运行时的功能
  3. 企业服务总线

（三）微服务

  微服务，顾名思义，就是很小的服务，所以它属于面向服务架构的一种。微服务的核心在于“小”，且专注于做一件事、轻量级的通信机制、独立部署。

  1. 微服务的优势
    技术异构性：服务与服务之间可以技术异构
    弹性：单个服务出现故障不会影响其他服务
    扩展：可针对单个服务进行扩展
    简化部署：每个服务的部署都是独立的，可以对特定代码进行修改而不影响其他服务
    与组织结构相匹配：服务的结构与切分能够与团队相匹配，避免系统规模过大影响团队协作
    可组合性：微服务架构提供很多接口供外部使用，从而构建不同形式的应用
  2. 微服务面临的挑战
    分布式系统的复杂度：采用微服务实现分布式系统复杂度更高（服务之间的网络通信）
    运维成本：每个服务都需要独立的部署、配置、监控、日志收集等
    部署自动化：每个服务都需要单独部署，人工成本高
    与团队组织结构的匹配
    服务间的依赖测试
    服务间的依赖管理
  3. 微服务与SOA
    微服务可以说是SOA的一种，但二者之间存在多方面的差异：

结语：

  笔者也只是一个初学者，写这篇文章更多的是记录自己的一些思考和想法。所以难免有不严谨或者错漏之处，请大家批评指正，不胜感激！后续还会继续更新关于学习微服务的内容，涉及项目构建工具、代码分析等内容，有兴趣一起学习的可以持续关注，交流心得！