卷首语：架构就是不断的选择、妥协与修正
在武侠世界里，高手之间需要不断的切磋，水平才能有所提升。在信息开放环境，和不同的高手交流，是保持自己信息处于最新状态的有效方法。
《人人都是产品经理》这本书大家应该不陌生。其实技术人也一样，不管是那个技术方向，都需要了解一些架构知识。比如前端的工程师需要了解架构，用什么框架，Web 方式还是 Native 方式？跨平台需要考虑如何测试，如何监测性能，如何确保安全性？这些都会遇到无数个架构选择。
机器学习工程师更需要了解架构，算法工程师开发出最前沿的算法模型，但是如果他不懂架构，不知道如何和大规模数据结合起来落地，就会重现“产品和研发打架”的情形。
架构能力取决于你的选择。有人说，人生就是不断选择的过程，其实即使作出选择，后期也会持续的变化、修正，这是一个不断积累的过程。从前端到后端，从大数据到人工智能，每个领域都有很多框架轮子。但是真的有必要过度追逐最新的技术吗？首先要看是否对业务或者系统有帮助，还要考虑投资回报比。此外还要关注所采用的框架作者或者社区是否能长期维护这个框架，现在很多技术像潮汐，来的快，退的也快，最好选择被广泛使用，靠得住的技术。
架构设计对于可扩展性要求较高，很大程度涉及到 API 的设计思路和服务边界，用 API 来支撑起服务的复杂度。系统简单的时候，如何选择都可以；但时间久了，系统复杂度很难管理。以搜索引擎前端为例，看上去很简单，但是有不同的团队在增加功能，需要适配不同的设备，Android、iOS 等，这就需要设计出“既不过于复杂，也不过于简单，恰到好处”的 API。
易用性是架构师该重点考虑的，因为你设计出来的产品是要给别人用的，用“同理心”去解决别人可能会遇到的问题。
另外，架构是需要不断演化不断优化的，无法维护那就重构。大多数技术负责人都很痛苦的一点是，很多历史遗留的 API 很难淘汰，维护很困难，用户又很多。这就需要在技术和业务之间做平衡，技术服务于业务的方向是对的，但是也不能受限于业务。就像最近讨论较多的“大中台、小前台”架构模式也是很好的尝试。
伟大的架构需要长期的磨练和时间的验证，过去 10 年里，很多大公司提了技术方案名称，但都消逝在时间浪潮里。技术的前进需要领头公司在系统上大量的投入，即使不确定方案是否奏效。架构师也是一样，在一线底层搭建系统实践，训练自己，沉住气，沉淀厚度。
目录
蘑菇街陈辉谈架构师业务思维修炼术
专访阿里亚顿：Serverless 正在颠覆开发模式，包括对工种的定义
作为中台倡导者，百度如何利用“搜索中台”实现月级别孵化新产品
唯品会自研微服务框架 OSP，解决拆分、扩容难题
字字珠玑，高级技术专家带你了解阿里的开发流程规范
阿里大文娱实践分享：业务架构如何影响中台建设？
七牛云许式伟：我所理解的架构是什么
评论