Software architecture is the basic structure of software.
Proper architecture is one of the most important factors for software success. Large software companies usually have a dedicated architect position (architect), only senior programmers can fill.
O'Reilly has published a free booklet , Software Architecture Patterns ( PDF ), which introduces the five most common software architectures and is a great primer. I benefited a lot from reading it, and the following are my notes.
1. Layered Architecture
Layered architecture is the most common software architecture and the de facto standard architecture. If you don't know what architecture to use, use it.
This architecture divides the software into several horizontal layers, each layer has a clear role and division of labor, and does not need to know the details of other layers. Layers communicate with each other through interfaces.
Although there is no clear agreement on how many layers the software must be divided into, the four-layer structure is the most common.
- Presentation: User interface, responsible for visual and user interaction
- Business layer (business): implement business logic
- Persistence layer (persistence): provide data, SQL statements are placed in this layer
- database (database): save data
Some software adds a service layer (service) between the logic layer and the persistence layer to provide some common interfaces required by different business logics.
The user's request will be processed through these four layers in turn, and any one of them cannot be skipped.
advantage
- Simple structure, easy to understand and develop
- Programmers with different skills can divide labor and be responsible for different layers, which is naturally suitable for the organizational structure of most software companies
- Each layer can be tested independently, and the interfaces of other layers can be solved by simulation
shortcoming
- Once the environment changes, it is usually cumbersome and time-consuming when code adjustment or function addition is required
- Deployment is cumbersome. Even if only a small place is modified, the entire software often needs to be redeployed, and it is not easy to do continuous release.
- During software upgrades, the entire service may be suspended
- Poor scalability. When a large number of user requests increase, each layer must be expanded in turn. Since each layer is internally coupled, it will be difficult to expand
2. Event-driven architecture
An event is a notification from the software when the state changes.
事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。
- 事件队列（event queue）：接收事件的入口
- 分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
- 事件通道（event channel）：分发器与处理器之间的联系渠道
- 事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作
对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。
优点
- 分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好
- 适用性广，各种类型的项目都可以用
- 性能较好，因为事件的异步本质，软件不易产生堵塞
- 事件处理器可以独立地加载和卸载，容易部署
缺点
- 涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂
- 难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚
- 分布式和异步特性导致这个架构较难测试
三、微核架构
微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。
优点
- 良好的功能延伸性（extensibility），需要什么功能，开发一个插件即可
- 功能之间是隔离的，插件可以独立的加载和卸载，使得它比较容易部署，
- 可定制性高，适应不同的开发需要
- 可以渐进式地开发，逐步增加功能
缺点
- 扩展性（scalability）差，内核通常是一个独立单元，不容易做成分布式
- 开发难度相对较高，因为涉及到插件与内核的通信，以及内部的插件登记机制
四、微服务架构
微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。
每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。
微服务架构分成三种实现模式。
- RESTful API 模式：服务通过 API 提供，云服务就属于这一类
- RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部
- 集中消息模式：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群
优点
- 扩展性好，各个服务之间低耦合
- 容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元
- 容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级
- 易于测试，可以单独测试每一个服务
缺点
- 由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳。
- 一旦服务之间需要通信（即一个服务要用到另一个服务），整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性。
- 分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。
五、云架构
云结构（cloud architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。
它的高扩展性，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元；访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，最好要进行数据持久化。
这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。
- 处理单元：实现业务逻辑
- 虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。
虚拟中间件又包含四个组件。
- 消息中间件（Messaging Grid）：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元。
- 数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
- 处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元
- 部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。
优点
- 高负载，高扩展性
- 动态部署
缺点
- 实现复杂，成本较高
- 主要适合网站类应用，不合适大量数据吞吐的大型数据库应用
- 较难测试
（完）