高内聚与低耦合

耦合：

耦合是指你每一个模块之间的依赖性，一个项目可以分为多个模块，按照Java项目的开发，每个模块会通过接口调用串联在一起。

我们的模块开发时，最重要的就是保证足够的独立性，这也是分模块的意义。模块关系越紧密， 耦合越强， 模块独立性越差。

举个例子(来源云+社区)：

比如模块A直接操作了模块B中数据， 则视为强耦合， 若A只是通过数据与模块B交互， 则视为弱耦合。

独立的模块便于扩展， 维护， 写单元测试， 如果模块之间重重依赖， 会极大降低开发效率。

网络异常，图片无法展示

|

内聚：

模块内部的元素， 关联性越强， 则内聚越高， 模块单一性更强。

也就是此模块自身的紧密度较高，独立性也相对强。如果按照较为优秀的开发规范，单个模块要能独立完成一个业务模块的功能需求。

低内聚的模块代码， 不管是维护， 扩展还是重构都相当麻烦， 难以下手。

如果有各种场景需要被引入到当前模块， 代码质量将变得非常脆弱， 这种情况建议拆分为多个模块。

网络异常，图片无法展示

|

百度对于内聚的描述也非常详细：

高内聚：躲进小楼成一统;

低耦合：各人自扫门前雪(牵一发而动全身)。

每个模块之间相互联系的紧密程度，模块之间联系越紧密，则耦合性越高，模块的独立性就越差！反之同理；

一个模块中各个元素之间的联系的紧密程度，如果各个元素（语句、程序段）之间的联系程度越高，则内聚性越高，即‘高内聚’ ！

高并发

在学习编程语言时，基本上都会学习并发编程的相关知识。

但是实际用到的机会也是较少的，因为只有业务发展起来，流量高了，才会要求并发。

通过设计保证系统能够同时并行处理很多请求。

随着流量变大，会遇到各种各样的技术问题，比如接口响应超时、CPU load升高、GC频繁、死锁、大数据量存储等等，这些问题能推动我们在技术深度上不断精进。

并发环境下，有一些指标去衡量并发，比如(此处资料来自CSDN)：

• 响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。
• 吞吐量：单位时间内处理的请求数量。
• QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。
• 并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

对于高并发环境下的业务，解决方案也很多，如：

• 缓存数据库，Redis等NoSQL数据库
• 数据库读写分离
• 负载均衡，Tomcat、Nginx、服务器负载均衡
• CDN优化、DNS优化等
• 硬件优化

如果想在面试中体现你对并发的了解，而达到一个优势的话，我觉得可以阅读一下这一篇：

高并发， 你真的理解透彻了吗？ - 知乎 (zhihu.com)

高可用

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。

比如我们的Redis，在刚诞生的时候，就有许多问题，比如宕机数据会丢失、单个服务死亡后没有替代品。

然后Redis不断优化，使用数据持久化、主从同步（主从复制）、Redis 哨兵模式（Sentinel）、Redis 集群（Cluster）这些技术来实现了高可用。

宏观的解释就是：

表示系统可以正常服务的时间。一个全年不停机、无故障；另一个隔三差五出线上事故、宕机，用户肯定选择前者。另外，如果系统只能做到90%可用，也会大大拖累业务。

分布式

我们Java去实现分布式，以前较多的是zookeeper+dubbo，现在可能SpringBoot+Spring Cloud比较多。

分布式系统是由多个节点组成的系统。而且这些节点一般不是孤立的，而是互通的。

不同的业务模块部署在不同的服务器上或者同一个业务模块分拆多个子业务，部署在不同的服务器上，解决高并发的问题，提供可扩展性以及高可用性。

分布式说起来其实逻辑是较为复杂的，概念也是较为抽象的。

我按照宏观的理解就是：

每个模块独立性很高，独立部署在不同服务器中，就是说，鸡蛋没有放在一个篮子里，用户要什么样的鸡蛋，就去对应篮子取，这样的好处不言而喻了吧。

说的有些模糊，但是我们仅仅是大致了解，欢迎大佬评论指出不足。