系统架构设计专题（目录）

在公司做系统架构设计的时候经常会碰到动不动就是架构的问题，要重新设计之类的。产品直接告诉技术如何实现，技术告诉产品业务流程应该怎样怎样设计之类。其实都是软件系统设计和业务、产品之间的关系没有理清楚。我在这里持续整理输出在实际工作中碰到的问题并总结出来，笔者也是不断学习和持续优化中。

系统架构师的职责

• 架构师分类与定位
• 涉众分析
• 系统建模
• 质量属性分析
• RUP 4+1视图表达方式
• 软件工程管理
• 项目管理（敏捷&DevOps）
• 本地事务Transaction
• CAP理论
• BASE理论

架构模式

描述的是一种关系（类与类的关系、组件与组件的关系）！并且这种关系是可复用的！

• Three-Tier 三层架构模式
• Multilayered architecture 多层架构模式
• Model-View-Controller(MVC) MVC模式
• Domain Driven Design 领域驱动设计模式
• Micro-Kernel 微内核模式
• Blackboard Pattern 黑板模式
• Sensor-Controller-Actuator 过程控制模式
• Presentation–Abstraction–Control 表示-抽象-控制

架构风格

架构风格即是约束！体系结构样式对设计施加约束，包括可显示的元素集，以及这些元素之间允许的关系。 约束通过限制所选的范围来引导架构的“形状”。 当某个架构符合特定风格的约束时，就会显现某些所需属性。
约束也会带来挑战，因此，在采用其中的任何风格时，必须了解各自的利弊。 该架构风格在该子域和界定的上下文中是否利大于弊？
下面是在选择架构风格时要考虑的一些挑战类型：

• 复杂性 该架构的复杂性对于域而言是否合理？ 反过来，该风格对于域而言是否过于简单？ 在这种情况下，风险是最终只设计出一个大泥球，因为该架构无助于利落地管理依赖项。

• 异步消息传送和最终一致性，异步消息传送可用于分离服务，并提高可靠性（因为消息可以重试）和可伸缩性。 但是，这也会在处理最终一致性方面带来挑战，并可能会导致出现重复消息。

• 服务间通信， 将应用程序分解为独立的服务时，风险是服务之间的通信会导致不可接受的延迟，或造成网络拥塞（例如，在微服务架构中）。

• 可管理性， 管理应用程序、监视、部署更新以及其他操作的难度有多大？

• CQRS 命令查询职责分离风格
• Component-based 基于组件风格
• Monolithic application 单体应用程序风格
• Layered (or multilayered architecture) 分层（或多层架构）风格
• Pipes and Filters 管道和过滤器风格
• Database-Centric 数据为中心
• Blackboard 黑板风格
• Rule-based 基于规则架构
• Event-driven aka implicit invocation 事件驱动又名隐式调用
• Publish-subscribe 发布订阅
• Asynchronous Messaging 异步消息
• Plug-Ins 插件
• Microkernel 微内核
• Reflection 反射
• Domain Specific Languages(DSL) 领域描述语言
• Client-Server (2-tier, 3-tier, n-tier exhibit this style) C/S风格（2-层，3层，n层）风格
• Shared Nothing Architecture共享体系结构风格
• Space-based Architecture 基于空间架构风格
• Object Request Broker 对象请求代理风格
• Peer-to-Peer 对等网络风格
• Representational State Transfer (REST架构风格)
• Service-Oriented 面向服务架构风格
• Cloud Computing Patterns 云计算模式
• MicroServices 微服务架构

分布式系统

分布式事务