关于后端:俯瞰-Java-服务端开发

原文首发于 github，欢送 star。

Java 服务端开发是一个十分广阔的畛域，要概括其全貌，即便是几本书也讲不完，该文将会提到许多的技术及工具，但不会深刻去解说，旨在以一个鸟瞰的视角去探寻这片畛域。

目录

• 目录

• 框架

  • Spring Boot
  • Vert.x

• 网络

  • 五层协定
  • HTTP 协定
  • TCP 拥塞管制
  • 网络 I/O 模型

• 数据库

  • 关系型数据库
  • 存储引擎
  • NewSQL
  • NoSQL 数据库
  • 时序数据库
  • 列式数据库
  • 嵌入式数据库

• 中间件

  • Web Server
  • 分布式缓存
  • KV 存储
  • 音讯队列
  • 定时调度
  • RPC
  • 数据库中间件
  • 日志零碎
  • 配置核心

• 微服务

  • 服务注册与发现
  • 熔断与降级
  • 链路追踪 / APM
  • API 网关
  • 服务网格

• 罕用开源组件

  • 数据拜访
  • 工具组件
  • 缓存
  • 字节码批改
  • http 客户端
  • 响应式编程
  • 序列化
  • 分布式事务
  • 事件驱动框架
  • 规定引擎
  • 测试

• 编程思维

  • 准则
• 结语

框架

Spring Boot

Spring 框架曾经成为 Java 服务端开发畛域里的标配，有数的服务基于其开发，它整合了服务端开发所需的绝大多数组件，Spring Boot 在其根底上又做了一层轻封装并简化了依赖治理，使得它用起来更加的便捷。

Vert.x

Spring 框架早已成为支流，然而咱们也不能疏忽了其余优良框架的存在。

Vert.x 是在 JVM 根底上构建响应式利用的一套工具集，反对多种语言，它不仅是一套工具集，也可视作是一套框架，其中蕴含应用 Netty 编写的 Web 框架、gprc、redis 客户端等泛滥组件，囊括了大部分开发网络应用时所需用到的组件，它最重要的外围概念是应用了事件驱动的非阻塞模型，因而具备高度的可伸缩性。它应用了响应式的编程模型，这个话题在下文中会再提到。

网络

五层协定

学习计算机网络时个别采纳折中的方法，也就是中和 OSI 和 TCP/IP 的长处，采纳一种只有五层协定的体系结构，即物理层、数据链路层、网络层、运输层、应用层，每一层都有其各自的术语，比方：吞吐量、子网掩码、VIP、DNS 等等，这在平时工作的沟通过程中也是至关重要。要做好服务端编程，咱们必须对网络的一些基本概念有一个清晰的意识，举荐浏览《计算机网络：自顶向下办法》。

举荐浏览：

• 五层协定
• 计算机网络常识总结

HTTP 协定

对于服务端编程而言，在网络这个局部最重要的还是 HTTP 协定，从 TCP、DNS，最初到浏览器响应，咱们必须分明整个过程是如何运行的，两头再退出 CDN、反向代理、流量管制等服务时，其会更加简单，但也正因为网络的分层模型，使得咱们能够在这个两头过程中对服务端的响应性能做出优化。

具体到 HTTP 协定，其承载于 TCP 协定之上，两头再加上 TSL 或 SSL，就成了 HTTPS，协定头如何解析，响应体如何发送，搞清楚了这些，能够很容易地开发一个简略的 HTTP 服务。HTTP 协定也在不断改进，目前曾经到了 2.0 版本，在传输性能上有大幅的晋升。

HTTP 应用明文传输，因而很容易受到中间人攻打，能够在路由器、代理等多个层面截获传输信息，因而 HTTP 终将退出历史舞台，HTTPS 必然成为支流，然而 HTTPS 也并非相对平安，因为证书签发机构存在安全漏洞，曾导致许多网站应用了不平安的 SSL 证书，因而很多利用会采纳自定义的加密形式来增强信息传输的安全性。

TCP 拥塞管制

TCP 应用多种拥塞控制策略来防止发送方至接管方之间的链路变得拥塞，其有许多具体的实现算法，具体的实现细节暗藏在操作系统的内核当中，通过应用不同的算法，能够在不同的场景下获得最佳的性能，例如 Google 设计并公布的 BBR（Bottleneck Bandwidth and Round-trip propagation time）拥塞算法，它能更无效地利用网络环境，尤其在超远距离的网络传输中能取得更大的性能晋升，目前曾经移植到 linux 内核 4.9 版本。

因为许多网络层相干的算法都暗藏在操作系统内核当中，一般计算机用户个别无需了解这些概念，然而对于服务端开发者来说，若对其有肯定的理解，则可能从这一层面寻找解决方案来晋升零碎的吞吐量。

网络 I/O 模型

常见 I/O 模型次要有 BIO（阻塞 I /O），NIO（非阻塞 I /O），I/ O 复用、事件 (信号) 驱动 I /O、AIO（异步 I /O）。以读取数据为例，传统的 BIO 外面调用 socket 的 read 办法，函数在收到数据前会始终阻塞，对于 NIO，如果有数据则返回，反之返回 0，不会产生阻塞，而 AIO 则更进一步，不光期待数据就绪是非阻塞，连数据从网卡到内存的过程也是异步的。

联合应用 NIO、AIO、I/ O 复用，能够解决线程瓶颈并解决海量连贯，比方 nginx 应用了 AIO 模型，因而性能比 apache http server 性能更好。在 Java 畛域，Netty 基于 Reactor 模式实现了一个异步事件驱动的 NIO 框架，其曾经使用在互联网的许多畛域，大到大数据、通信行业、游戏行业，小到 redis 客户端、Web 框架等开源组件都有其身影。

数据库

关系型数据库

MySQL 是最风行的开源数据库，PostgreSQL 是最高级的开源数据库，SQL Server 是微软开发的企业级数据库，还有在大型公司用的较多的 Oracle 数据库。在服务端开发方面，MySQL 的市场占用率是最高的，但也举荐学习一下 PostgreSQL 和所谓的「企业级数据库」，毕竟 MySQL 在这些数据库背后有时的确显得性能简略、实用性有余。

在实在的工作中，数据库的设计是一个十分须要均衡取舍的过程，有时为了优化查问性能不得不做一些数据冗余，而在数据量极大的状况下，又必须审慎抉择每一列的存储类型、防止冗余。

数据量十分大的状况下，大多数时候还要进行分库分表的设计。

• ShardingSphere

  • 目前 Java 中支流的分库分表中间件，反对客户端架构、代理架构，Sidecar 架构目前还在开发中。

• Vitess

  • Vitess 是 Youtube 开源的 MySQL 数据库集群零碎，采纳的是中心化的数据库代理架构，这套数据集群承载了 Youtube 数以亿计的数据量和拜访申请。

存储引擎

MySQL 中支流应用的是 InnoDB 存储引擎，外部采纳了 B+ 树的索引构造，Percona XtraDB 是 InnoDB 存储引擎的增强版，Percona 兼容 MySQL，号称领有更好的性能，也具备肯定的市场占有率。

除了 InnoDB 及其衍生引擎，RocksDB 也是一个可选项，这是一个 LSM 存储引擎，不同于传统的基于 B+ 树的存储引擎，基于 LSM 存储引擎的数据库尤其适宜写多读少的场景，因为最后是设计用来做长久化的键值数据存储，因而在 KV 存储上具备十分高的性能，惋惜的是 MySQL 无奈抉择 RocksDB 作为存储引擎，目前反对的数据库有 MariaDB 和 Percona。

NewSQL

NewSQL 这一新兴畛域也大量应用了 RocksDB 作为存储引擎，TiDB 作为风行度较高的 NewSQL 产品，就是用其实现的数据长久化。

NoSQL 数据库

• MongoDB

  • MongoDB 介于关系数据库和非关系数据库之间，不要求数据存储具备固定的模式，且能用于存储超大规模的数据集。

时序数据库

随着互联网的深刻，利用场景越来越丰盛，诸如零碎运行状态、零碎指标采集等场景产生大量的数据，这类基于工夫的一系列数据，以写多读少、数据量极大为特点，传统的数据库曾经不适宜存储这类数据，时序数据库由此诞生。

支流的时序数据库有：

• influxdb
• Prometheus
• graphite

列式数据库

传统的关系型数据库采纳行式存储，大数据畛域多采纳列式存储，列式存储的次要劣势在于能够按需所取，在并行处理和数据压缩上更有劣势。关系型数据库适宜 OLTP，列式数据库更适宜 OLAP，为了使列式数据库能更好地反对 OLTP，目前呈现了像 kudu 和 Druid 这类优良的开源产品，它们联合了列式存储的劣势，并在 OLTP 方面也做了特地的优化。

支流的列式数据库有：

• HBase
• Cassandra
• kudu
• Druid

嵌入式数据库

传统的关系型数据库可能反对企业级的利用，但在许多场景下，咱们可能只须要一个小型利用，这个时候应用嵌入式数据库是一个不便的抉择，除此之外，嵌入式数据库非常适合用于做单元测试。

Java 中风行的嵌入式数据库有：

• h2base
• moby

中间件

Web Server

• Nginx

  • Nginx 应用 AIO 的模型实现高并发，Apache 每个申请独占一个线程。
  • AIO 模型适宜于 IO 密集型服务，多过程或线程适宜于 CPU 密集型服务，因为大多数 Web 服务都属于 IO 密集型，nginx 的市场占有率逐步超过了 Apache。因为这一特点，Nginx 也非常适合做反向代理，通过这种机制做负载平衡也是十分支流的一种计划。

• tomcat、jetty、weblogic 等传统 Java Web 服务器

  • 随着容器化技术的风行，这类服务器日渐式微，市场占有率逐步降落，进行容器化部署时 tomcat 个别内置在程序中，这种提高使得开发者能够更关注业务代码自身，而无需关注此类服务器的种种细节，堪称是对开发人员的减负。

• OpenResty

  • 优良的开源产品经常出现许多优良的衍生产品，比方 Percona 之于 MySQL，OpenResty 之于 Nginx，Kong 之于 OpenResty。
  • Nginx 市场占有率之高，但许多场景下是用其做反向代理，OpenResty 的设计指标则是让 Web 服务间接跑在 Nginx 服务外部。
  • OpenResty 同时也是基于 LuaJIT 的 Web 平台，开发者能够很不便地应用 Lua 调用 Nignx 模块，具备弱小的可扩展性，比方可将典型的 Nginx + Tomcat + MySQL 架构更换为 Nginx + Lua + Redis + Tomcat + MySQL 的架构。
  • Kong 从技术上讲也属于 Web Server，但个别用来做 API 网关，下文中再详述。

分布式缓存

• Redis

  • Redis 作为一个高性能的内存数据库，目前已被宽泛应用，其反对多种数据结构，依据不同场景应用不同的数据结构，能力最无效地应用它。

KV 存储

• Pika

  • Redis 的性能十分高，但在将其做数据库应用时存在数据长久化的问题，Pika 就是为了解决这一问题而呈现，它底层基于 RocksDB，批改了其局部源代码，在 KV 数据长久化上有十分高的性能，与基于内存的 redis 相比仅有较小的性能降落，同时它还兼容大部分的 redis 协定，与 Redis 的应用简直没有差别，上手简略。

• Tair

  • Tair 与 Pika 相似，底层反对多种存储引擎，包含 mdb、rdb、ldb，其中 ldb 基于 leveldb（google 开源，rocksdb 在其根底上优化），它可将内存存储和长久化相结合，具备高可用的分布式架构，目前开源版本曾经不再保护，阿里云上则提供了企业级的 Tair 存储服务。

• SSDB

  • SSDB 也是兼容 Redis 的一款 KV 数据库，目前更新频率较低，相比而言 Pika 目前还在更新中，且有企业进行背书。

音讯队列

音讯队列在申请削峰、跨零碎间通信解耦、公布订阅等许多场景下都会应用到，不光能解决这些问题，采纳音讯驱动的架构能够加强零碎的扩展性，比方新增一个订阅方，即能够实现新的性能，并且对以后的零碎没有任何的侵入性。

罕用的音讯队列产品有 kafka、rabbitmq 等，它们各有优缺点，在大数据畛域 kafka 占有绝对优势，总体的市场占有率也较高，而 rabbitmq 因为产品成熟，也被宽泛应用。

在应用音讯队列的过程中，须要解决一系列的细节，比方：定义音讯解决者、如何发送音讯、如何公布事件、音讯如何序列化、如何记录音讯记录、设计音讯路由、音讯解决失败的重试机制、音讯 id 等等，在具体的编码过程中不能齐全专一于业务代码开发，因而市面上有一些 ESB 产品在外部解决好了这些细节，并从更高的形象层级提供更加简洁的 API，在开发过程中则能更加聚焦在业务逻辑自身，当咱们的零碎面临这些问题的时候，无妨抉择一个 ESB 产品来晋升研发效率。

定时调度

简略的定时工作能够采纳 linux cron 进行配置，简单的场景也能够应用分布式任务调度框架，可选的实现形式十分多，这里简略的列举几种。

• Quartz

  • 老牌任务调度零碎，许多分布式任务调度框架基于它而扩大。

• Spring Scheduler

  • 用它来做简略的任务调度十分不便，但要留神因为当初的零碎大多采纳分布式部署，因而当应用它来做任务调度时最好做到独自的服务中，防止与其余零碎耦合。

• 国产分布式任务调度零碎

  • 目前较为风行的有 Elastic-Job、XXL-JOB，Elastic-Job 采纳去中心化的架构，依赖 zookeeper 存储任务调度数据，XXL-JOB 采纳中心化调度的架构，调度采纳 RPC 形式。
  • PowerJob 是新兴的一个开源任务调度零碎，在性能上更为弱小，反对 MapReduce 分片，值得关注。

RPC

提到 RPC 不得不提到日暮西山的 Web Service，其采纳 XML 作为音讯格局，并以 SOAP 协定进行封装，因为过于简单且性能开销较大，其逐步被采纳 JSON 格局的 REST 服务所取代，相比之下，REST 简略且采纳更高效的序列化形式，所以目前许多零碎宽泛采纳 HTTP 的形式进行近程过程调用。

在对于性能要求特地高的场景，或从整体架构上思考，人们才会选用专门的 RPC 产品，这类零碎个别领有更高效的通信协定和数据传输格局，典型的有 dubbo、grpc、thrift，其中 grpc 具备最优良的性能。

RPC 框架的原理其实与 HTTP 调用相似，只是采纳了更精简的协定头和数据序列化形式，此外在服务注册发现及负载平衡上也做了专门的封装。在 Spring Cloud 中，应用 OpenFeign 进行服务间调用是十分不便的一个抉择，其应用 HTTP 形式，当性能无奈满足时，可思考替换序列化形式，或选用 grpc 进行通信。

数据库中间件

数据库自身就是一个宏大的产品，除了后面提到的 ShardingSphere、Vitess 这类中间件，还有一类专门做数据处理的中间件。

• otter

  • 分布式数据库同步零碎，反对 MySQL、Oracle。

• canal

  • 基于 MySQL 数据库增量日志解析，提供增量数据订阅和生产。

• DataX-Web

  • 分布式数据同步工具，可用来简化 ETL 工作。

• gh-ost

  • 对数据表构造进行架构变更时，可能导致表被锁住，如果数据量特地大，这种问题对于线上公布的影响是比拟大的，能够采纳建新表并迁徙数据再批改表名的形式手工解决，这种形式容易出错且耗时，Github 开源的 MySQL 在线架构迁徙工具则是程序化实现这一类操作的很好的抉择。

日志零碎

• ELK

  • 日志零碎个别采纳 ELK 技术栈，这其中蕴含三个子系统，因而要扩大一个新性能，能够有多种形式切入，比方做监控报警，能够应用 logstash 将 metrics 写入到 Prometheus，也能够应用 kibana 上的 sentinl 插件或者 ElastAlert 插件。
  • logstash 反对从许多管道收集数据，其中包含 kafka，在日志量特地大的状况下，能够将日志先发送至 kafka。

• Sentry

  • 日志在很大一部分场景下都是用于排查谬误的，除了 ELK 外还有专一于应用程序错误报告的零碎，比方 Sentry。

配置核心

因为越来越多的零碎基于 docker 部署，配置核心不仅能够简化零碎的配置管理，也可简化零碎的公布流程，目前较为风行的开源配置核心是 Apollo。另外也能够通过 zookeeper、Consul 等工具来实现对立配置管理。

Nacos 是阿里开源的一款集配置核心和注册核心于一体的零碎，应用它来做配置核心也较为不便，服务端部署相比 Apollo 简化了许多。

微服务

因为单体利用牵一发而动全身的特点，许多大型利用在开发时都会盲目拆分为多个子系统，这是在微服务概念提出前就被宽泛采纳的形式，而微服务概念的提出则更进一步，提出了一种全新的零碎开发方式，使零碎能够不便地拆分到更小的粒度，即微型服务，那么在服务数量越来越多的状况下，服务治理、熔断降级、链路追踪等问题也浮出水面，于是解决这些问题的 Spring Cloud 框架冉冉升起。

服务注册与发现

支流的服务注册与发现组件有：Eureka、Consul、Nacos 等等，它们采纳不同的 CAP 分布式一致性规定或多种都反对，但不论应用哪一种，其实还是存在服务失联的问题，比方在滚动更新的过程中，注册核心未能及时剔除掉服务，导致调用方仍在调用进行的服务，首先咱们能够通过调整配置缩小更新周期，必要时须要批改其源代码，应用长连贯，只有连贯中断即从注册核心剔除服务，具体的细节须要专门写一篇文章来解说。

在可能的状况下，尽量应用音讯机制来进行服务间通信，这是一个更好的抉择，除了更好地进行解耦，在滚动更新这个局部也能更好地放弃零碎不间断运行。

熔断与降级

服务间的调用过多，肯定水平上减少了零碎的耦合度，当其余微服务出问题或响应较慢时，整个零碎都受影响，在必要时须要对出问题的服务进行熔断或降级。

• Hystrix

  • Spring Cloud 框架默认集成的熔断组件。

• Sentinel

  • Spring Cloud Alibaba 中集成的熔断组件，提供了一个内部控制台，能够实时调整零碎的熔断降级配置，在这个局部强于 Hystrix。

链路追踪 / APM

服务间相互调用，使得调试变得比单体利用简单不少，这个时候应用链路追踪工具可能简化调试，同时也可能对应用程序的性能有更直观的监控。

支流的链路追踪组件有：

• zipkin
• pinpoint
• SkyWalking
• jaeger

API 网关

Spring Cloud 体系中罕用的网关前有 Zuul，后有 Gateway，这一类跟 Spring Cloud 联合严密，使用方便，但因为它们都是 Java 写成，在许多场景下还是比不上一些专门的网关产品。

• Kong

  • Kong 是 OpenResty 的衍生开源网关产品，领有优良的性能和丰盛的插件，可满足许多的扩展性需要。

• Traefik

  • Traefik 是用 Go 语言编写的网关，定位是云原生的边界路由网关产品，它领有丰盛的个性、易用的控制面板，与云原生场景深度联合，提供了实时的流量指标可对接到 Prometheus 中。其企业版蕴含限流、高可用等个性，开源版在这一部分有所缺失。

服务网格

从单体利用到微服务的演进，咱们会发现服务治理、熔断、Tracing 这些简直是必不可少的局部，即便是应用 Spring Cloud 框架，咱们也须要关注大量的微服务技术细节，为了拆散这一关注点并使这些技术成为基础设施个别的存在，服务网格应运而生。

什么是 Service Mesh（服务网格）？

服务网格好比微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说个别毋庸关怀 TCP/IP 这一层（比方通过 HTTP 协定的 RESTful 利用），同样应用 Service Mesh 也就毋庸关怀服务之间的那些本来通过服务框架实现的事件，比方 Spring Cloud、Netflix OSS 和其余中间件，当初只有交给 Service Mesh 就能够了。

目前支流的服务网格有：

• Istio
• Linkerd

罕用开源组件

上文有提及的，这里不再累述。

数据拜访

• MyBatis Plus
• Mapper
• jOOQ
• JPA
• dynamic-datasource-spring-boot-starter
• sharding-jdbc

工具组件

• guava
• commons-lang3
• hutool

缓存

• redission
• jetcache
• caffeine

字节码批改

• asm
• javassist
• cglib

http 客户端

• okhttp
• Aache HttpClient
• retrofit
• openfeign

响应式编程

• RxJava
• reactor-core

序列化

• protobuf
• protostuff
• hessian

分布式事务

• seata

事件驱动框架

• AxonFramework

规定引擎

• drools

测试

• junit
• mockito
• Spock

编程思维

编程思维是一个形象的概念，要将其具象化咱们必须透过景象看其本质，优良的编程思维是对各种优良想法的组织，这些想法能够精炼成许多准则，准则是形成编程思维的一个重要局部，也是所有编程形式都能够恪守的通用准则。在准则的根底上，在编码过程中重复解决的一些问题又被演绎为模式，这两者是思维的次要形成，另外也有不同的编程范式及方法论，我在这里简略的讲一下设计准则。

准则

很多准则不仅实用于编程畛域，也实用于其余畛域，我想这也是为什么乔布斯提倡人人都应该学习编程，因为它能让你领有更好的思考形式。

• 放弃简略

  • Keep It Simple, Stupid (KISS)

    • 最重要的准则之一，牢靠来源于简略，只有一直放弃零碎的简略、代码的简略，能力更好地发明优良的软件。

  • You Ain’t Gonna Need It (YAGNI)

    • 如无必要，勿增复杂性，防止适度设计。

  • Separation of Concerns (SoC) – 关注点拆散

    • 将指标相关联的局部封装在一起，标识为关注点。这是升高复杂性的一个重要准则，MVC 或 MVP 模式都是该准则的利用，将模型、视图和控制器作为不同的关注点，使得每一个关注点能够更无效地了解及重用。
    • 在编码过程中，也能够利用这一思维，比方咱们首先关注应用程序是否可用，当其运行正确后再关怀运行效率，这比同时进行这两项工作要简略的多。

• 不要反复

  • Don’t Repeat Yourself (DRY)

    • 最简略也最容易了解的准则，每个程序员都应该以随便复制粘贴代码而感到惭愧。

  • Convention over Configuration（CoC）- 常规优于配置准则

    • 将约定的配置形式和信息作为缺省的规定来应用，能够缩小开发人员做决定的数量，缩小编码量，取得简略的益处，又不会失落灵活性。
    • Spring Boot 框架解决的问题之一就是简化我的项目的配置，其大量利用了 CoC 准则。

• S.O.L.I.D 准则

  • Single Responsibility Principle (SRP) – 繁多职责准则

    • 一个类，只做一件事，并把这件事做好，其只有一个引起它变动的起因。
    • 很简略的准则，然而很多程序员在工作时常常违反这一准则，比方一个 service 类中引入许多 dao 对象，提供多种不相干服务。

  • Open/Closed Principle (OCP) – 开闭准则

    • 模块是可扩大的，而不可批改的。也就是说，对扩大是凋谢的，而对批改是关闭的。
    • 设计模式中的代理、策略和观察者模式比拟好地实现了这一准则。
    • 当咱们定义的一个 API 可承受函数作为参数时，实际上也是一种策略模式的变体，同样也体现了这一准则。

  • Liskov substitution principle (LSP) – 里氏代换准则

    • 子类必须可能替换成它们的基类。
    • 这个准则可作为咱们设计类继承关系的基准。

  • Interface Segregation Principle (ISP) – 接口隔离准则

    • 对接口进行拆分，应用多个专门的接口比应用繁多的总接口要好。
    • 接口能够多继承，那为何要因为懈怠而将其轻易定义在一个总接口里呢？

  • Dependency Inversion Principle (DIP) – 依赖倒置准则

    • 高层模块不应该依赖于低层模块的实现，而是依赖于高层形象。
    • IoC 是 DIP 的一个具体实现，其曾经深刻到编程语言当中，Spring 框架最后就只是作为一个 IoC 容器，而后才一直扩大出许多实用功能并最终成为一个开发框架。
    • 相干准则：Hollywood Principle – 好莱坞准则（所有的组件都是被动的，所有的组件初始化和调用都由容器负责）。

• 高内聚、低耦合

  • Law of Demeter – 迪米特法令

    • 又称“起码常识准则”（Principle of Least Knowledge），一个类对于其余类晓得的越少越好，晓得的越多其耦合水平就越高。
    • 门面模式和中介模式都是迪米特法令利用的例子。
    • 这一准则强调低耦合。

  • Common Closure Principle（CCP）– 独特关闭准则

    • 如果必须批改应用程序里的代码，咱们心愿所有的批改都产生在一个包里（批改敞开），而不是遍布在很多包里。
    • 在微服务架构中，若批改一个性能时，常常须要批改多个服务，那么其很有可能违反了 CCP 准则不恰当地进行了服务拆分。
    • 这一准则强调高内聚。

  • Common Reuse Principle (CRP) – 独特重用准则

    • 包的所有类被一起重用，没有被一起重用的类不应该被组合在一起。依赖一个包就是依赖这个包所蕴含的所有。
    • CCP 则让零碎的维护者受害，CCP 让包尽可能大（CCP 准则退出性能相干的类），CRP 则让包尽可能小（CRP 准则剔除不应用的类）。它们的出发点不一样，但不互相抵触。
    • 这一准则同样强调高内聚。

结语

正如结尾所言，服务端开发畛域极其宏大，本文还有许多枝节尚未提及，比方平安、DevOps 等等。技术的演进使这个畛域减速扩充，将来还会有许多的变动，兴许 Service Mesh 将会成为支流，兴许 NewSql 将成为开发标配，任何一门技术的演进历史变长，它的总体学习工夫相应也会减少，但这并不意味着对其的利用也会变得复杂，咱们不能漠视云计算这一因素，云服务的提供为开发者暗藏了许多的细节，在这个时代不须要通晓每一项技术的原理，也可能开发出服务千万用户的产品。

将来会演进成什么样，能够去期待，但不要只是去期待，因为将来曾经到来，只是还没有均匀散布。