架构，如果让你给它一个定义，恐怕一时不好表达。正如，问你，山，是什么；水，是什么一样。对于程序员来讲犹如游山玩水的侠客，畅游在程序-代码-架构之中。为架构，下一个定义，和为山水，下一个定义，一样可能会略作沉思之后，方能概述。
微服务是一种架构风格。曾经也思考，微服务，到底是先有了微服务这个动作，还是先有微服务这个名词。想到此，想起我们的祖先，拿来一个木棍，在另外一根木棍上，使劲旋转，生出火来。后来，我们为其取了一个名词：钻木取火。因此，微服务也恐怕是这样，我们实践了分布式架构的动作，后又继续尝试精进更能符合业务和组织的方法。后来有技术达人总结为：微服务。
我们再说回架构，架构一定是为应用程序服务的，那么应用程序的需求是什么，有两个，一个是功能性需求，实现一些什么样的功能，这些功能的实现是通过代码编写最终完成；另外一个是非功能性需求，包括这套应用程序的可维护性、可测试性、可扩展性和可部署性。这个非功能性需求便是架构要解决的问题。
对于功能性需求你完全可以用一个"大肚子"应用程序去实现，只有对我们说的非功能性需求有要求的时候，也一定会对这样的非功能性需求有要求的，因为你肯定不希望自己的程序不可维护、不可测试、不可扩展和不可部署。非功能性需求更是一种能力，是应用程序健壮与否的能力，是程序的"肌肉"。
那架构是什么，你可以清晰的为之定义了吗？
程序的架构，有时候我们往往与建筑架构类比，更有意思的一点是，在英语中 建筑师 和 架构师 是同一个词architect。建筑架构，一般有结构、管线、电气等多个构成。那么程序架构呢，早在不少年之前，国外就有这方面的专家，提出了4+1的视图模型来描述架构。
4+1视图中的4，有逻辑视图、实现视图、进程视图、部署视图。其中的1，是场景。场景来负责把视图串联在一起。这种视图模型表示法是对现代化应用程序架构一个准确的描述，放在我们如今广泛使用的微服务架构中能很清晰的给出精准的定位。无论如何架构，都会涉及逻辑、实现、进程和部署。
架构有它的风格，在类比到建筑上。建筑架构的风格可以有 "大裤衩"的豪放之风，也可以有细腻的江南水乡之风。程序的架构也有它的风格，分层式的架构是一种风格，为其代表的是MVC；六边形的架构是一种风格，定义了端口和适配器，解耦了业务逻辑和依赖；微服务是一种架构风格，将应用程序构建为松耦合、可独立部署的一组服务。
计算机软件已经发展了那么多年，开发程序仍然是一个需要认真对待的复杂过程。无论今天你如何敏捷，定义问题、需求分析、软件架构、详细设计、编码与调试、单元测试、集成测试、保障维护，这些动作都少不了。你承认不承认都会在大脑中和行动上经历这些动作，而架构活动是软件开发中的核心活动。
那么架构师呢？
架构，对于架构师，是解决问题的工具，如果架构不能解决问题，架构对于架构师就是一个玩具。
