- 推荐序一:架构师真正要学会的事情
- 推荐序二
- 译者序 2.0
- 序
- 关于本书
- Part Ⅰ 什么是软件架构
- 第 1 章 什么是架构
- 第 2 章 架构的种类
- 第 3 章 软件架构是什么
- 第 4 章 敏捷软件架构是什么
- 第 5 章 架构对上设计
- 第 6 章 软件架构重要吗
- 第 7 章 问题
- Part Ⅱ 软件架构的角色
- 第 8 章 软件架构的角色
- 第 9 章 软件架构师应该编码吗
- 第 10 章 软件架构师应该是建造大师
- 第 11 章 从开发者到架构师
- 第 12 章 拓展 T
- 第 13 章 软技能
- 第 14 章 软件架构不是接力运动
- 第 15 章 软件架构要引入控制吗
- 第 16 章 小心鸿沟
- 第 17 章 未来的软件架构师在哪里
- 第 18 章 每个人都是架构师,除非他们有其他身份
- 第 19 章 软件架构咨询师
- 第 20 章 问题
- Part Ⅲ 设计软件
- 第 21 章 架构驱动力
- 第 22 章 质量属性(非功能需求)
- 第 23 章 处理非功能需求
- 第 24 章 约束
- 第 25 章 原则
- 第 26 章 技术不是实现细节
- 第 27 章 更多分层等于更高复杂度
- 第 28 章 协同设计是一把双刃剑
- 第 29 章 软件架构是对话的平台
- 第 30 章 SharePoint 项目也需要软件架构
- 第 31 章 问题
- Part Ⅳ 可视化软件
- 第 32 章 沟通障碍
- 第 33 章 对草图的需要
- 第 34 章 无效的草图
- 第 35 章 C4:语境、容器、组件和类
- 第 36 章 语境图
- 第 37 章 容器图
- 第 38 章 组件图
- 第 39 章 是否包含技术选择
- 第 40 章 你会那样编码吗
- 第 41 章 软件架构和编码
- 第 42 章 你不需要 UML 工具
- 第 43 章 有效的草图
- 第 44 章 C4 的常见问题
- 第 45 章 问题
- Part Ⅴ 为软件生成文档
- 第 46 章 代码不会讲述完整的故事
- 第 47 章 软件文档即指南
- 第 48 章 语境
- 第 49 章 功能性概览
- 第 50 章 质量属性
- 第 51 章 约束
- 第 52 章 原则
- 第 53 章 软件架构
- 第 54 章 外部接口
- 第 55 章 代码
- 第 56 章 数据
- 第 57 章 基础设施架构
- 第 58 章 部署
- 第 59 章 运营和支持
- 第 60 章 决策日志
- 第 61 章 问题
- Part Ⅵ 开发生命周期中的软件架构
- 第 62 章 敏捷和架构的冲突:神话还是现实
- 第 63 章 量化风险
- 第 64 章 风险风暴
- 第 65 章 恰如其分的预先设计
- 第 66 章 初识软件架构
- 第 67 章 问题
- Part Ⅶ 金融风险系统
- 第 68 章 金融风险系统
- Part Ⅷ 附录:技术部落 的软件指南
第 37 章 容器图
一旦通过语境图了解了你的系统如何融入整个IT环境,真正有用的下一步就是通过容器图说明高层次的技术选择。
意图
容器图可以帮助你回答下面的问题。
1.软件系统的整体形态是什么样的?
2.高层次技术决策有哪些?
3.职责在系统中如何分布?
4.容器之间如何相互交流?
5.为了实现特性,作为一个开发者,我需要在哪里写代码?
结构
画一个简单的框图来展示你的关键技术选择。比如,如果画金融风险系统的解决方案图,根据你的解决方案,大概会画出下面这样的图。
金融风险系统(见附录)的容器图示例
这些示例图展示了组成风险系统的不同的Web服务器、应用服务器、独立应用程序、数据库、文件系统,等等。包含一些语境图的概念往往对丰富内容很有用,比如用户和风险系统依赖的其他IT系统。
容器
这里说的“容器”,指的是组成软件系统的逻辑上的可执行文件或过程,诸如:
Web服务器1(比如Apache HTTP服务器、Apache Tomcat、微软IIS、WEBrick等);
应用服务器(如IBM WebSphere、BEA/Oracle WebLogic、JBoss AS等);
企业服务总线和业务流程编排引擎(如Oracle Fusion中间件等);
SQL数据库(如Oracle、Sybase、微软SQL服务器、MySQL、PostgreSQL等);
NoSQL数据库(如MongoDB、CouchDB、RavenDB、Redis、Neo4j等);
其他存储系统(如亚马逊S3等);
文件系统(特别是如果你在数据库以外读/写数据);
Windows服务;
独立/控制台应用程序(即“public static void main”风格的应用程序);
Web浏览器和插件;
cron和其他计划的工作容器。
1如果多个Java EE Web应用程序或.NET网站是同一个软件系统的部件,通常会在单独的类加载器或应用程序域里被执行。我用单独的容器来展示它们,因为它们是独立的,要靠进程间通信(比如远程方法调用、SOAP、REST,等)来协同工作。
图上的每一个容器都可以指定下面这些项。
名称:容器的逻辑名称(如“面向互联网的Web服务器”、“数据库”等)。
技术:容器的技术选择(如Apache Tomcat 7、Oracle 11g等)。
职责:容器职责的高层次声明或清单。你也可以展示一张驻留在每个容器中关键组件的小图,但我发现这通常会把图搞得很乱。
如果你纠结于容器图中是否要包含一个框,只要问自己,这个框是否会(或者能)部署到一个单独的物理或虚拟硬件上。你展示在容器图上的每件东西都应该能够单独部署。这并不意味着你必须将它们部署在单独的基础设施上,但它们应该能够单独部署。
交互
容器间的通信通常是进程间通信。明确这一点并总结这些接口将如何工作是很有用的。和其他任何图相同,它对于标注交互行为非常有用,而不仅仅是由一堆框和连接它们的含混的线组成的图。下面是一些有用的信息:
交互的目的(如“读/写数据”、“发送报告“等);
通信方法(如Web服务、REST、Java远程方法调用、Windows通信基础、Java消息服务);
通信方式(如同步、异步、批量、两阶段提交等);
协议和端口号(如HTTP、HTTPS、SOAP/HTTP、SMTP、FTP、RMI/IIOP等)。
系统边界
如果你选择将不属于你构建范畴的用户和IT系统囊括其中,在适当的容器周围画一个框来明确地标定系统边界可能是个好主意。系统边界对应了语境图上的一个框(比如“风险系统”)。
动机
语境图展示的软件系统是一个盒子,容器图则是打开盒子,展示里面的东西。这很有用,因为:
让高层次的技术选择更明确;
展示了哪些容器之间有关联,以及它们如何沟通;
提供了一个放置组件的框架(也就是说,所有的组件都有一个家);
展示了高层次的语境图和通常很乱的组件图之间经常缺失的连接,组件图画的是整个软件系统中所有的逻辑组件。
和语境图一样,画容器图应该只需要几分钟时间,因此真的也没有理由不做这件事。
受众
直接从事软件开发的团队内部和外部技术人员;包括从软件开发者到运营和支持人员的每一个人。
示例
下面这张图展示了组成“技术部落”网站的逻辑容器。
“技术部落”—容器
简单地说,“技术部落”由一个向用户提供信息的Apache Tomcat Web服务器组成,而信息则通过独立的内容更新进程来保持最新。
所有数据都被存储在MySQL数据库、MongoDB数据库或文件系统当中的一个。值得指出的是,这张图并未提及每个容器的物理实例的数量。比如,可能有一片运行在MongoDB集群上的Web服务器,但这张图并未展示这个层次的信息。相反,我在一个单独的部署图上展示了物理实例、故障转移、集群等。容器图展示了软件架构的高层次形态,以及职责如何分布。它也展示了主要的技术选择以及容器如何相互交流。这是一个简单的高层次技术图,对软件开发者和支持/运营人员很有用。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论