笔者认为，对中大型系统而言，服务架构要符合如下几个特性：
- 高度服务化，可扩展 大中型系统必须分层，把各个非业务性的、通用化的功能独立成服务提供能力输出，可以方便地增加或是修改现有服务，一个理想的系统应该是业务规模与服务的重用度成正比，公司规模越大、产品线越丰富，可重用的服务越多
- 削峰填谷，易伸缩 大中型系统的硬件成本是个不可忽视的因素，恰到好处地利用系统资源，在业务高峰期自动增加服务资源以提升高发能力，在业务低谷期又可自动释放服务资源以节省开销
- 小版本，快迭代 现代软件开发，尤其是互联网产品比的就是速度，谁的需求影响及时谁就有主导权，在业务体量大、形式复杂的前提下架构要避免牵一发而动全身，常规项目做到1、2周一个版本，特殊情况下早上提的需求晚上就可以发布
- 完全分布式，高性能 性能是绕不过去的话题，架构上必须有全盘性的考量，在一些传统的ToB软件行业流传着一种说法：与其用投入性能优化的精力还不如加机器更划算。这一观点在特定项目中有其合理性，但纵观整个行业，性能都是重中之重的指标，尤其是大型互联网企业。单点是个不可忽视的问题，服务分布式了，依赖的中间件有没有单点？数据库、缓存、对象存储是不是集群化的？ 注册调用、配置管理、网关是否是高可用的？进一步而言，每个服务的运维、开发是不是有备份的？这些都是我们要处理的单点
- 安全可靠，可维护 安全是最为基础的要求，但同时也是最难的要求之一，从机房的运维守则到规范化的发布流程，从数据存储的灾备方案到生产数据的访问策略，从编码的基础安全意识到运维的可靠性保障这些无一不是重点难点。从架构上需要对运维提供友好的支撑，在安全、可维护上做足功夫
要实现这几点并不简单，传统的架构只能覆盖某几点，而微服务架构在很大层面上可以满足这些需求或是为其实现提供了可能。但在谈微服务之前我们再看上面的这些特性可以发现除软件架构本身的要求外它还需要业务产品方与开发的紧密配合、测试自动化快速回归的能力、运维规范化容器化建设的成熟等诸多人的因素、依赖环境的因素的共同协作。
⚠ 不要为了微服务而微服务，微服务实施的前提是业务、产品、开发、测试、运维在各自领域内做到了高度专业化、流程化，同时又可以彼此配合默契。如果你的团队尚不成熟请务必认真评估、谨慎使用。 🔆 微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。详见此处
微服务（Microservices）一词可追述到2005年[Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System ComplexityWeb Services Edge 2005 East]，可见它并不是一个新鲜的概念。笔者观察到现在还有大量关于它与SOA对比的文章[soa-vs-microservices] ，这和前些年讨论REST与SOA有些相像，其实SOA的立意很高、概念很抽象且不断演进，无可争议的是微服务是符合SOA架构风格的，但它与传统的SOA又有一些区别，主要体现在：
- 微服务要求以服务为单位，拆分的粒度更细 传统SOA多以系统为节点通讯，微服务更强调将每个系统再拆分形成一个个独立的服务单元
- 微服务更分布式，去中心化 微服务不需要ESB，强调服务协同(Choreography)而不是编排(Orchestration)
- 各服务可自运行，无需外部容器 使用集中化的诸如Tomcat、JBoss容器不够敏捷，对可伸缩性也有比较大的影响，因此微服务要求每个服务节点可独立运行，独立对外提供服务
以上的区别使得微服务相较传统的SOA有如下优势：
- 业务响应快 按细粒度业务单元拆分，新增或业务变更只需要修改小部分服务即可提测、发布，在微服务架构下每个服务都有明确的边界及接口锲约，每个服务功能聚焦、代码可控，所以可大幅度地缩短开发、测试到发布的周期
- 复用率高 更小的粒度意味着更多的可复用性，避免重复造轮子，以服务为单位，越是丰富的产品线越能体现出功能复用的价值，越往后业务的支撑越会类似“搭积木”式的服务拼装形式
- 可靠性高 去中心化、集群化，降低了单点故障，同时没有单点依赖，性能调优上有了更多的可操作方案
- 硬件投入少 高峰期自动扩容、低谷期自动缩减，可实现以服务为单位的细粒度的资源管控，实现对资源恰到好处地使用
- 开发成本低 支持不同技术栈服务，开发人员可使用自己擅长的技术，不同服务场景可以选择最合适的技术实现，比如对算法相关的服务可以使用C++，稳定的应用服务使用Java，易变的业务使用NodeJs等
正因为有这些优势，现在很多项目都在尝试微服务，但真正成功实施微服务的项目少之又少，这其中有很多是对微服务的误解与误用。只有与业务、团队适配、开发实施得当才能发挥微服务的优势，反之会导致项目失控，事与愿违。
关于微服务本节只启了个头，接下来的各个章节都会围绕微服务展开，但诚如本书开篇所言，微服务介绍性的书籍、文章太多了，本书会尽量避免重复。微服务架构已被广泛认可，过多地介绍微服务的各种优势已没有太大必要，相反的笔者会从实践出发以微服务实施的挑战为切入从另一个方向去解释微服务不是银弹，引入这一架构会有很高的门槛、会有一定的项目团队要求，同时也会介绍各个挑战可能的解决方案以供大家评估。
在一众咨询微服务转型的机构中绝大部分笔者都礼貌地劝谏不要转微服务，在笔者的观念中各个做微服务介绍的meetup、做咨询的机构或是做布道的培训如果让受众因此成功地实施了微服务那有很大的功劳，但如果让受众因此放弃了微服务那也不失为其重要的成果。本书也是如此，不是推销微服务，而是帮助大家在全面了解微服务后做出正确的选择，与结果用不用微服务无关。
下一节：为了更好地让读者理解服务架构，本书会带读者完成一个真实的系统，这个系统的选择会考察两个因素：
1. 普遍性，尽量是ToC的，大家都有接触，以避免花太多篇幅介绍业务背景，当然培训机构用烂了的”XX商城“不在考虑之内
2. 与笔者实际工作有关，这样才能在适合本书主旨的同时力求项目背景及核心需求的真实性
笔者服务过三家互金公司，从零开发过一套完整的车贷管理系统，对这块有一定的经验。 因而本书都会围绕“信贷管理系统“地建设展开。各位读者不妨将自己设定为此项目组的一员，在下文中带入自己的思考。由于篇幅有限，介绍上会突出重点，读者多为服务端开发，也为切合本书主旨，笔者会聚焦服务端并与微服务架构有关的内容。为更好阐述微服务架构，本书会此系统做一定裁剪及发散。