（点击上方的蓝色文字，可快速关注我们）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，只聊架构，不聊其他！打造最有价值的架构师圈子和社区。

长按下方的二维码可以快速关注我们

如想加群讨论学习，请点击右下角的“加群学习”菜单入群。