软件架构师到底都做些什么？架构准则？微服务应用的4层架构？

架构师的角色

软件架构师的职责是什么呢？许多公司都会招聘软件架构师，即便这个职位的实际工作效果和对它的要求出入很大。

微服务应用使得快速修改成为可能：因为团队在不断地开发新的服务、停用现有服务或者重构现有功能，所以应用也会随着时间慢慢地演进。架构师或者技术负责人的工作就是要确保系统能够不断演进，而不是采用了固化的设计方案。如果微服务应用是一座城市的话，开发者就是市政府的规划师。

架构师的职责是确保应用的技术基础能够支持快节奏的开发以及频繁的变化。架构师应该具备纵观全局的能力，确保应用的全局需求都能得到满足，并进一步指导应用的演进发展。

（1）应用和组织远大的战略目标是一致的。

（2）团队共同承担一套通用的技术价值观和期望。

（3）跨领域的内容——诸如可观察性、部署、服务间通信——应该满足不同团队的需要。

（4）面对变化，整个应用是灵活可扩展的。

为了实现这些目标，架构师应该通过两种方式来指导开发：第一，准则——为了实现更高一层的技术目标或者组织目标，团队要遵循的一套指南；第二，概念模型——系统内部相互联系以及应用层面的模式的抽象模型。

架构准则

准则是指团队为了实现更高的目标而要遵循的一套指南（或规则）。准则用于指导团队如何实践。这一模型如图3.3所示。例如，如果某产品的目标是销售给那些对隐私和安全问题特别敏感的企业，那么开发者就要制定这些准则。

（1）开发实践必须符合那些公认的外部标准（如ISO 27001）。

（2）时刻牢记，所有数据必须是可转移的，并且在存储数据的时候要有效期限制。

（3）必须要能够在应用中清晰地跟踪和回溯追查个人信息。

准则是灵活的，它们可以并且应该随着业务优先级的变化以及应用的技术演进而变化。例如，早期的开发过程会将验证产品和市场需求的匹配度作为更高优先级的工作，而一个更加成熟的应用可能需要更专注于性能和可扩展性。

图3.3　基于技术准则的架构方法

微服务应用的4层架构

架构应该体现出清晰的高层概念模型。在对一个应用的技术结构进行分析时，模型是一个非常有用的工具。如图3.1中的3层模型，这样的多层模型是一种应用程序结构的常见方案，能够反映整个系统不同层次的抽象和职责。

在本章的其余部分中，我们会探讨微服务的4层模型。

（1）平台层——微服务平台提供了工具、基础架构和一些高级的基本部件，以支持微服务的快速开发、运行和部署。一个成熟的平台层会让技术人员把重心放在功能开发而非一些底层的工作上。

（2）服务层——在这一层，开发的各个服务会借助下层的平台层的支持来相互作用，以提供业务和技术功能。

（3）边界层——客户端会通过定义好的边界和应用进行交互。这个边界会暴露底层的各个功能，以满足外部消费者的需求。

（4）客户端层——与微服务后端交互的客户端应用，如网站和移动应用。

上述架构层次如图3.4所示。不管底层使用了什么技术方案，开发者应该都能够将它应用到所有微服务应用中。

图3.4　微服务应用架构的四层模型

每一层都是建立在下一层次的功能之上的，比如，每个服务都会利用下层的微服务平台提供的部署流水线、基础设施和通信机制。要设计良好的微服务应用，需要在每个层级上都进行大量的投入并精心设计。

很棒！开发者现在有了一个可用的模型。在后续的5节中（略），我们会一一介绍这一架构模型的4个层次，并讨论它们对构建可持续的、灵活的、可演进的微服务应用的贡献。

本文摘自《微服务实战》

这是一本关于微服务应用的开发和部署主题的书，非常有实用性。本书解决了将微服务部署到生产环境的难题，是写给那些对面向服务开发技术掌握得比较扎实的开发人员和架构师的。基于读者对传统系统的理解，本书会先对微服务设计原则进行比较深入的概述，然后会指导读者如何将服务可靠地发布到生产环境。在学习搭建集群和维护这些已部署的系统时，本书中的例子会用到Kubernetes、Docker和Google Container Engine这样的工具和技术。

本书所使用的技术适用于以大部分流行的编程语言开发的微服务。在本书中，我们决定以Python作为主要语言，因为它的风格比较自由，语法比较简洁。这样可以使书中的代码示例可以更加清晰和明确。如果读者不熟悉Python，也不用担心——在运行这些代码时，我们会专门进行说明。