软件架构师到底应该做什么，又为什么这么难做好，这都是近来的热门问题，我也一直在和朋友们讨论。正巧，最近我看完了新鲜出炉的《微服务设计》，所以大概可以谈谈自己的看法了。因为这类问题比较抽象，也没有统一答案，我努力尝试把思路整理清楚，把表达变得流畅。最终有没有讲清楚，说的对不对，欢迎大家给我留言。

今天看来，传统的软件开发（尤其是应用型软件开发）其实是相对简单的。软件运行在基本可靠的单机环境下：CPU提供计算能力，内存提供动态存储，总线提供数据传输，硬盘提供永久存储。这些概念稳定而直观，程序员要完成的，就是调用和组装编程语言提供的各种功能，来满足现实的需求。相比应用程序员良莠不齐的开发水平，无论是操作系统还是硬件环境，都是来自大公司的工业级别的产品，是值得信赖的。

如果把程序要完成的功能比作个人，软件运行的环境比作房屋，那么房屋虽小，却是值得信赖的。对个人来说，只要进去了房屋里，就有相对稳定的环境，相比野外生存就是巨大的进步。当然，如果遇到意外情况，在野外可能生存机会大一点，在房屋里只能与房子“一损俱损”了。不过，通常来看这不要紧。

随着计算机要解决问题日趋复杂，出现了可复用的类库。它们把重复的功能包装起来，只要直接拿来就可以使用。回到房子的比喻，这些东西就好像标准化制作的家用电器，你搬回去、看懂说明书、用起来，就可以大大提升自己的效率。

上面说的是软件内部的进化，软件外部运行模型仍然相对简单——无论要解决什么任务，各种逻辑和资源都是处在同一个运行时（runtime），或者能够方便可靠访问的运行时当中。如果需要提升性能，除去软件本身的优化，就是升级硬件。如果我们需要更快的计算速度，就必须升级CPU；如果我们需要更多的动态存储，就必须升级内存…… 虽然升级需要停机，但是升级之后，性能提高了，运行环境的稳定可靠却不受影响。回到房屋的比喻，在这种思路下，房子还是原来的房子，只是建造得越来越高级，越来越稳定。

即便业界提出了N层模型，整体的复杂度提升也有限。这种划分往往并不是严格按照业务责任，还考虑了实现特性，而且层与层之间的接口仍然能依赖外部环境保持稳定可靠。比如常见的三层模型，表现层-业务逻辑层-数据库层，表现层与业务逻辑层之间往往是函数调用，业务层与数据库层之间的通常是通过安全稳定的内网连接，数据库则是配置很好的机器保证高可用性。回到房屋的比喻，这种思路很像花重金建造几栋紧密相连的专用房屋，各自对应不同的用途。如果外界环境变化不大，这种设计确实很稳定，但也很不灵活。

随着互联网的飞速发展，程序要解决的问题的复杂度也在飞速，原有的思维和范式，既要考虑业务，又要考虑实现，应对起来已经非常吃力了。所以，SOA（面向服务的架构）的概念应运而生。SOA基本脱离了技术实现的细节，引导开发人员从业务和抽象的“服务”角度来看待系统。与传统复用只考虑静态的代码和类库不同，SOA复用的则是动态的运行着的服务。

以上两点，都是SOA相对传统软件开发思想的巨大进步。可惜的是，大多数SOA的学说更倾向于理论和概念的层面，服务的“粒度”究竟定在哪个层级，服务如何落地保证可用性…… 这些问题始终没有取得广泛的共识和规范，对于软件所依赖的环境，SOA也很少涉及，但软件的运行是离不开外部环境的。所以SOA的学说虽然热门，但真正做到了、做好了的例子非常有限。

回到房屋的比喻，SOA不太关心每栋房子到底干什么，只是从逻辑上做个大致的区分：这片房子分给商人，那片房子分给农民，另一个片区的房子分给工人…… 但是SOA并不会具体地规定每个区域里应当安排多少房子，这些房子应当如何建造，如何组合，所以区域里很可能有混乱。

技术继续发展，尤其是移动互联网的兴起，极大地增加了软件所要解决问题的复杂度。从内部来说，性能的增长已经改变了方向，无论CPU还是内存，性能的增长都不再来源于单纯部件的提高，而更多来自多个普通部件的协同工作。如果说传统的性能提高是从纵向上考虑，现在则是从横向上考虑，承载计算能力的不再是“一颗高运算速度的CPU”，保存动态数据的也不再是“一片大容量内存”。玩法变了，程序的思维和编写范式也需要随之进行调整。

从外部来说，性能提升而运行环境仍然稳定的好事不复存在，运行环境日益复杂，可靠性也随之下降，已经没有哪家软件和硬件厂商能为系统提供足够可靠的运行环境。这种外部的挑战很难和以前一样依靠外部供应商来解决：廉价服务节点莫名崩溃很可能是家常便饭，如果网络完全要求节点自身质量过硬以提供高可用性，不但代价高昂，而且违背了网络设计“容忍故障”的初衷；大量程序调用现在通过网络而不是本地进行时进行，几乎无处不在的超时限制会逼迫大家采用异步调用，传输速度和稳定性也会受到极大限制——分布式系统设计中的重大谬误之一就是认为“网络是可靠的”。

更糟糕的是，SOA未能解决的粒度问题变得要紧起来。传统的软件系统大致都有规格说明书，在设计时就要考虑每个子系统的承载能力，而且这些能力大致是彼此协调彼此关联的，系统运行时应当保证压力不超过设计规格。但是现在，业务的飞速发展很可能把段时间内就压力集中到单个服务甚至其中的少数功能上，跨服务的功能很可能又需要迅速组合成新的服务，而这种变化是事先根本无法预料的，很容易暴露出服务定义的粒度问题。再者，从整体上考虑，每个服务既要保证自己的稳定，又要相对隔离以限制故障的影响，同时还要适度容忍其它服务的不稳定，最终才能从总体上保证系统的稳定。这，也是对传统开发思维的一大挑战。

在这种局面下，“微服务”应运而生了。承接SOA的概念，它把系统按照业务责任划分为彼此独立的多个服务，既保证了概念的清晰和自洽，又保证了系统的灵活性、伸缩性。面对杂乱不可靠的现实，它又从实现上注重每个服务的自治性，也就是能独立部署，具备自动化、可观察、故障隔离、自动恢复等特性，由此提供高可用保障。同时，微服务又抛弃了SOA中的很多概念，比如难以落地的ESB、UDDI等等。

在SOA尚且没有完整落地的时候，对它有继承有更新有颠覆的“微服务”，极大增加了开发人员的挑战。首先，服务要拆得足够小，又不至于太小，这样才能保证伸缩性并隔离故障；其次，不能因为服务“小”就降低保障级别，维护一堆“小服务”的保障级别，这是极其麻烦的事情；再次，要做到上面这一切，无论是从理论学说上还是从可依赖的软硬件系统上，都没有现成的低成本的解决方案；最后，因为维护的是动态的“服务”，传统静态的“代码所有权”和“机器所有权”的划分不再有效，它们已经融合为统一的“服务所有权”，它属于开发人员、运维人员以及所有相关人员的共同体，这又会带来团队配合与分工的挑战。

回到房屋的比喻，其实这个比喻此时已经完全不合适了。现在的系统更像高度复杂的城市，而不是单独的房屋，所以架构师也不像建筑设计师，而更像城市规划师，他的职责是对城市进行规划，确定每个区域应该做的事情，这些区域应当达到统一的规范要求，又具有随时扩张或缩减的灵活性；同时，他还应当保证这种划分适合对应的专业人员在对应区域工作。

明白了这一点，就可以明白版本管理、持续集成、自动化测试、自动化发布、服务治理、详尽监控等等“磨刀工夫”的价值——没有这些工作，就谈不上微服务的质量和保障级别，也就无法驾驭微服务的体系。

由此，也很容易明白架构师在这个时代要面对的挑战。一方面，他没有现成的足够强大的集成工具，只能靠一堆“稀松平常”的工具组装出整体可靠的系统；另一方面，他又要深入理解业务，把业务拆散成边界清晰的概念，以高内聚低耦合的服务分而治之，还必须考虑到实现的限制——“高内聚低耦合”的原则人人都知道，如果没有可靠的分布式事务管理机制，就不得不把并非“高内聚”的模块聚合起来，但你又要担心业务边界模糊的风险；RESTful固然优雅，但有时候又不得不使用RPC通讯，所以你又要提防RPC带来的强绑定、客户端服务器端同步更新等很多问题……

这一切设计、权衡、决策，并没有成型的理论和学说可以依靠，通常只能完全依赖架构师的经验、理解、思考。所以困难很大，风险也很大，如果做得好，收益也是非凡的。而这，恰恰是架构师的价值所在。

推荐《微服务设计》这本书，实际上我觉得书名翻译不够准确，Building Microservices更合适的名字应当是“构建微服务的学问”。

这本书非常全面，高屋建瓴地描述了微服务的整体面貌，也详细介绍了微服务的方方面面，从设计到实现，从开发到运维。可以说，这本书虽然只有薄薄的的200页，但已经覆盖了一个称职的分布式系统架构师应当思考的问题，和应当掌握的技能。

我更欣赏的是，书中对很多概念的讲解非常客观，并没有绝对的臧否。我自己很早就发现很多系统里业务责任混乱，数据库实际上充当了业务逻辑层。但和其他朋友讨论起来，大家也只是表示无奈。

《构建微服务》的作者就专门讲到了“用数据库集成”作为服务的设计，指出它的好处是实现简单迅速，问题则是容易对外暴露实现细节，并且对服务消费方的技术选择做出了严格而不灵活的限定。此外关于同步/异步调用的选择，RESTful和RPC的对比，JSON和XML的适用场合，都做了相当客观的评价。相信大家看完之后可以更深刻地理解这些技术，在实践中做选择时更有把握。