某技术公司技术二面面试题总结

存在一个单体架构的服务，怎么拆分为微服务的架构

将一个单体应用程序拆分成微服务架构是一个复杂的过程，需要深入的计划和实施。以下是一般的步骤和策略，可以帮助您成功地将单体应用程序拆分为微服务：

理解单体应用程序：
- 首先，深入了解您的单体应用程序，包括其架构、模块、功能和依赖关系。这将为拆分过程提供基础。
确定微服务边界：
- 确定哪些功能或模块可以独立运行，并将其定义为潜在的微服务。微服务应该有明确的边界和清晰的职责。
设计API：
- 为每个潜在的微服务设计API，定义如何与其他微服务通信。这包括确定API的终端点、数据格式和认证/授权方式。
拆分数据存储：
- 如果单体应用程序使用共享数据库，考虑将数据存储拆分为微服务专用的数据库或数据存储。这有助于避免数据泄漏和提高微服务的独立性。
引入通信机制：
- 选择一种适当的通信机制，如RESTful API、消息队列或gRPC，以便微服务之间进行通信。确保通信是可靠和高效的。
实施微服务：
- 开始逐步实施微服务，从单体应用程序中提取功能并将其部署为独立的微服务。可以采用逐步迁移的方法，逐步替换单体的功能。
监控和日志：
- 设置监控和日志系统，以确保您可以实时监控和诊断微服务的性能和健康状态。这对于故障排除和性能优化至关重要。
负载均衡和扩展：
- 实施负载均衡策略，以确保流量均匀分配给不同的微服务实例。同时，确保您可以根据需要扩展微服务。
安全性：
- 确保每个微服务都有适当的安全性措施，包括身份验证、授权和数据加密。微服务之间的通信应该是安全的。
测试：
- 进行全面的测试，包括单元测试、集成测试和端到端测试，以确保微服务在各种情况下都能正常工作。
部署和运维：
- 建立适当的部署流程和自动化，以便可以轻松部署新版本和进行维护。
监督和优化：
- 持续监督微服务架构的性能，根据需要进行优化和调整。

拆分单体应用程序为微服务是一个复杂的任务，可能需要时间和精力，但它可以提供更高的灵活性、可伸缩性和独立性，有助于更好地满足不断变化的业务需求。因此，在拆分过程中要仔细计划和实施，并确保团队具备足够的知识和技能来管理微服务架构。

spring cloud微服务架构，把gateway服务去除掉，怎么设计

如果您要将 Spring Cloud 架构的微服务中的 Gateway 移除，需要重新设计和调整微服务架构，以适应新的需求。以下是一些可能的设计思路：

直接客户端到微服务通信：
- 允许客户端直接与微服务通信，而不经过网关。客户端需要知道每个微服务的终结点，并根据需要进行请求路由和负载均衡。您可以使用服务发现工具（如Eureka、Consul或Zookeeper）来帮助客户端发现可用的微服务实例。
使用反向代理：
- 引入一个反向代理服务器，充当网关的角色，但不包含网关的所有功能。这个反向代理可以处理基本的请求路由和负载均衡，但不涉及身份验证、鉴权等功能。这有助于降低客户端的复杂性。
在微服务内部处理安全性：
- 由于移除了网关，您需要在每个微服务内部实施适当的安全性措施，例如基于令牌的身份验证（JWT）或OAuth 2.0。每个微服务都负责验证和授权请求。
处理跨域资源共享（CORS）：
- 如果客户端跨域请求多个微服务，需要在每个微服务内部配置适当的CORS规则，以允许跨域请求。
监控和日志：
- 移除网关后，需要在每个微服务内部配置监控和日志记录，以确保您可以追踪和监控系统的性能和健康状态。

需要注意的是，移除网关可能会增加系统的复杂性和维护成本，因为网关通常提供了集中化的管理和控制。因此，这个决策应该根据具体的需求和复杂性来权衡。如果没有特殊要求，通常建议保留网关，以提供额外的控制和功能。

一个docker容器部署的服务，一个docker容器部署的mysql数据库，现在部署服务的容器报timeout error，请问遇到这种问题，怎么排查问题？

当您遇到 Docker 容器部署的服务出现 “timeout error” 问题时，以下是更具体的排查步骤和详细说明：

查看容器日志：
- 使用以下命令查看服务容器的日志：
```
docker logs <container_id>
```
- 查看日志中是否有任何异常、错误或警告消息。这些消息可能包含与问题相关的详细信息。
检查服务配置：
- 检查服务容器的配置，包括环境变量、配置文件和启动参数。确保它们与服务的期望配置一致。特别注意数据库连接字符串和端口设置。
网络连接问题：
- 运行以下命令测试服务容器是否能够与数据库容器建立连接：
```
docker exec -it <service_container_id> ping <database_container_ip>
```
- 如果 ping 不通，检查容器网络设置和防火墙规则，确保容器之间的通信没有问题。
数据库连接：
- 验证服务容器中的数据库连接配置是否正确。确保连接到 MySQL 数据库的主机名、端口、用户名和密码正确。
- 尝试从服务容器内连接到数据库容器并执行一个简单的 SQL 查询，以验证数据库是否可用。
容器健康检查：
- 如果您使用 Docker 的健康检查功能，请查看服务容器的健康检查状态：
```
docker inspect --format='{
       
       {json .State.Health.Status}}' <service_container_id>
```
- 确保健康检查状态正常。如果它报告问题，查看健康检查命令和配置。
端口映射：
- 如果服务容器和数据库容器位于不同的网络，请确保 Docker 容器之间的端口映射正确设置。例如，服务容器需要能够访问数据库容器的端口。
防火墙和安全组规则：
- 如果您在云上运行 Docker 容器，请检查云提供商的防火墙规则或安全组规则，确保容器之间的通信没有被阻止。
服务日志：
- 如果服务容器是自己编写的应用程序，查看应用程序的内部日志以获取更多信息。检查是否有与请求超时相关的错误或异常记录。
容器资源限制：
- 检查容器的资源限制，例如内存和 CPU。如果容器资源不足，可能会导致服务响应超时。

根据排查的结果，采取适当的行动来解决问题。可能需要更新容器配置、修复代码错误、修复数据库问题或重新配置网络设置。重要的是不断迭代排查步骤，仔细检查问题的根本原因，并采取适当的措施来解决 “timeout error” 问题。

TPS的性能要求是2000/s,设计微服务需要注意那些地方

设计一个微服务系统以满足每秒 2000 个事务（Transactions Per Second，TPS）的要求需要仔细考虑系统架构、性能优化和水平扩展。以下是一个概要的系统设计，以满足这个 TPS 要求：

系统架构：
- 使用微服务架构，将应用程序拆分为多个独立的微服务，每个微服务负责不同的功能。
- 使用容器化技术（如Docker）来部署微服务，以提高部署和扩展的灵活性。
负载均衡：
- 在系统的入口点引入负载均衡，将请求均匀分发到多个微服务实例。
- 使用负载均衡器（如NGINX、HAProxy或云提供商的负载均衡服务）来处理入口流量。
数据库：
- 使用高性能的数据库系统，如分布式数据库（例如Cassandra、MongoDB）或关系型数据库（例如MySQL、PostgreSQL）。
- 考虑数据库缓存和索引优化，以提高查询性能。
缓存：
- 使用缓存技术，如Redis或Memcached，来缓存频繁访问的数据，减轻数据库负载。
- 使用缓存失效策略，确保缓存数据的时效性。
消息队列：
- 引入消息队列（如RabbitMQ、Apache Kafka）来异步处理后台任务，以减轻同步请求的压力。
- 将任务异步化，以提高系统的响应性和性能。
水平扩展：
- 使用容器编排工具（如Kubernetes）来自动化和简化微服务的水平扩展。
- 根据需求动态添加或移除微服务实例，以满足不断变化的负载。
性能监控：
- 集成性能监控工具（如Prometheus、Grafana）来实时监控系统的性能指标。
- 设置警报规则，以在性能问题发生时及时采取措施。
安全性：
- 实施安全性措施，包括身份验证、授权、数据加密和漏洞扫描，以保护系统的数据和功能。
- 使用Web应用程序防火墙（WAF）来防止恶意攻击。
自动化部署和CI/CD：
- 建立自动化部署流程，使用持续集成/持续交付（CI/CD）工具来自动构建、测试和部署微服务。
- 这有助于快速交付新功能和修复问题。
容灾和备份：
- 设置容灾和备份策略，以确保系统在硬件故障或其他灾难情况下具有高可用性和可恢复性。
- 定期备份数据，并测试恢复过程。
监控和日志：
- 使用日志收集工具（如ELK堆栈）来收集和分析系统日志。
- 配置监控警报，以在系统问题发生时及时通知运维团队。
容量规划：
- 进行容量规划，以确保系统可以满足未来的增长需求。考虑硬件升级、数据分区和扩展性。
CDN和静态资源缓存：
- 使用内容分发网络（CDN）来缓存静态资源，减轻服务器负载并提高全球访问速度。

以上是一个高层次的设计概要，以满足每秒 2000 个 TPS 的要求。具体的系统设计和架构将取决于您的应用程序需求、技术栈和预算。确保在系统开发和维护过程中密切关注性能和可伸缩性，并根据需求进行调整和优化。

怎么实现数据库的读写分离

实现 MySQL 数据库的读写分离是一种常见的数据库优化策略，它可以提高数据库的性能和可扩展性。读写分离的基本思想是将读操作和写操作分开，以便分摊数据库服务器的负载。以下是实现 MySQL 读写分离的一般步骤：

准备主从复制架构：
- 在 MySQL 中，读写分离通常基于主从复制（Master-Slave Replication）架构实现。主服务器（Master）用于处理写操作，从服务器（Slave）用于处理读操作。
- 需要确保主服务器上的数据与从服务器保持同步。
创建从服务器：
- 在数据库中创建一个或多个从服务器。这些从服务器将用于处理读操作。
- 需要确保从服务器的配置与主服务器的配置相匹配，包括数据库架构和表结构。
配置主从复制：
- 在主服务器上配置主从复制。这涉及到创建一个用于复制的 MySQL 用户，并在主服务器上启用二进制日志（Binary Log）。
- 在从服务器上配置复制连接，以便从主服务器获取更新数据。
设置读操作的路由：
- 为了实现读写分离，需要在应用程序中设置读操作的路由机制，以将读请求发送到从服务器。
- 通常，可以通过以下方式实现路由：
  - 使用数据库连接池或数据库客户端，配置它们以在读操作时连接到从服务器。
  - 在应用程序中使用负载均衡器来分发读请求到多个从服务器。
监控和故障转移：
- 设置监控系统，以检测主服务器和从服务器的状态。如果主服务器发生故障，需要自动切换到另一个主服务器。
- 在主从复制中，可以设置自动故障转移机制，以确保数据的高可用性。
处理数据一致性：
- 由于主从复制存在一定的延迟，需要处理从服务器上数据的一致性问题。读操作可能读到稍旧的数据。
- 如果需要强一致性，可以在应用程序中采用其他策略，例如在写操作后立即读取主服务器上的数据。

需要注意的是，读写分离是一项复杂的任务，需要谨慎的规划和配置。在配置主从复制时，确保数据的完整性和一致性，并考虑到故障恢复机制。此外，了解应用程序的读写模式和性能需求对于正确实现读写分离非常重要。

线上出现CPU 100%的情况，怎么去排查

要详细排查服务器 CPU 利用率达到 100% 的情况，您可以使用各种工具和方法。以下是一些更具体的步骤：

使用top或htop工具：
- 运行以下命令以查看当前系统的 CPU 使用情况，按 CPU 利用率降序排列进程：
```
top
```
  或者使用 htop 工具，它提供了更友好的交互界面：
```
htop
```
- 查看哪些进程占用了最多的 CPU 资源。可以查看 PID（进程ID）、用户、CPU 使用率、内存使用情况等详细信息。
查看特定进程的详细信息：
- 在 top 或 htop 中，选中高 CPU 使用率的进程，然后按 Shift + H 键查看该进程的线程详细信息。
- 这将显示哪个线程正在占用 CPU 资源，有助于确定问题的具体源头。
使用perf进行性能分析：
- perf 工具可以用于系统性能分析，包括 CPU 使用情况。以下是使用 perf 的一些命令示例：
  - 查看 CPU 活动：
```
perf stat -a sleep 1
```
  - 查看函数调用堆栈：
```
perf record -e cpu-clock -g -- sleep 5
perf report
```
查看进程的strace输出：
- 使用 strace 工具可以跟踪进程的系统调用，从而帮助确定问题的根本原因。例如：
```
strace -p <pid>
```
查看系统日志：
- 检查系统日志文件，通常位于 /var/log/syslog（对于Debian/Ubuntu系统）或 /var/log/messages（对于CentOS/RHEL系统）。查找与 CPU 问题相关的错误或警告消息。
使用性能监控工具：
- 使用性能监控工具（例如，Prometheus、Grafana、Zabbix）来持续监控服务器的 CPU 使用情况，并设置警报以在 CPU 利用率超过阈值时收到通知。
检查数据库性能：
- 如果服务器是数据库服务器，使用数据库性能分析工具（如mysqladmin、pg_stat_statements）来分析数据库查询和索引性能。
检查后台任务：
- 确保没有后台任务或定时任务正在占用 CPU 资源。查看和管理系统的定时任务（使用crontab -l命令）。
资源监控工具：
- 使用工具如 sar 或 vmstat 可以查看服务器的资源利用情况，包括 CPU、内存、磁盘和网络。

一旦确定了问题的原因，根据情况采取适当的行动，可能需要优化或停止具有高 CPU 使用率的进程，升级硬件，优化数据库查询，或者进行其他性能调整。持续监控服务器性能，并定期进行性能分析，以确保服务器正常运行。

如果检查下来不是进程造成的cpu 100%，应该排查什么方向

如果在排查了进程占用 CPU 的情况下未找到明显的原因，而服务器仍然出现 CPU 利用率达到 100% 的问题，那么您可以考虑以下其他方向来排查问题：

硬件问题：
- 检查服务器硬件健康状况。可能存在故障的硬件组件，如 CPU、内存、磁盘或电源供应等。
- 使用硬件诊断工具来检测潜在的硬件问题。
操作系统问题：
- 更新操作系统内核和驱动程序，以确保系统获得最新的安全补丁和性能改进。
- 检查操作系统的配置是否正确，包括文件系统、内核参数等。
恶意软件和病毒：
- 进行病毒扫描和恶意软件检测，确保服务器没有受到恶意软件或病毒的感染。
虚拟化或容器化问题：
- 如果服务器运行在虚拟化环境或容器化平台上，检查宿主机资源的使用情况，确保宿主机没有资源争用问题。
网络问题：
- 检查网络流量和连接是否异常。可能存在网络攻击或大规模的连接尝试，导致服务器 CPU 使用率升高。
异常系统行为：
- 检查系统的异常行为，如异常重启、内存泄漏等。这可能需要检查系统日志和监控工具的数据。
其他资源问题：
- 检查其他系统资源，如内存、磁盘、网络带宽等是否受限制，这可能会影响 CPU 的性能。
性能分析工具：
- 使用性能分析工具（如 perf、strace、dtrace）来深入分析系统性能问题，查找具体原因。
应用程序层问题：
- 考虑应用程序本身是否存在性能问题，例如死锁、内存泄漏、低效率的算法等。对应用程序进行性能分析和优化可能有助于解决问题。
监控和警报系统：
- 设置监控和警报系统以实时监测服务器的各种性能指标，以便在出现异常时能够及时收到警报。

如果在上述排查步骤中未找到问题的根本原因，可能需要进行更深入的系统诊断，可能需要考虑咨询专业的系统管理员或工程师来帮助解决问题。服务器性能问题可以有多种原因，因此需要综合考虑各种因素来找到问题并采取适当的措施解决它。

liunx 命令：替换error.log中的 xxxx字符串替换成yyyy字符串

要替换一个文件中的字符串，您可以使用 sed 命令。假设您要将 error.log 文件中的所有 xxxx 字符串替换为 yyyy 字符串，可以执行以下命令：

sed -i 's/xxxx/yyyy/g' error.log

这个命令使用 -i 选项表示直接在文件中进行替换操作。s/xxxx/yyyy/g 是替换的操作符，s 表示替换，xxxx 是要查找的字符串，yyyy 是要替换成的字符串，g 表示全局替换，即替换所有匹配的字符串。

执行这个命令后，error.log 文件中的所有 xxxx 字符串都将被替换为 yyyy 字符串。请确保在执行这个命令之前备份您的文件，以防意外情况。

单体服务和微服务的优缺点

单体服务和微服务是两种不同的软件架构模式，它们各自具有一系列优点和缺点，适用于不同的应用场景和需求。以下是单体服务和微服务结构的主要优缺点：

单体服务（Monolithic Architecture）：

优点：

简单维护和部署：由于应用程序是一个整体，因此单体服务的部署和维护相对简单。通常只需要部署一个单一的应用程序。
开发速度：单体服务可以更容易快速开发，因为它们的代码和数据模型都位于同一个代码库中，开发人员之间的协作更容易。
性能：对于某些类型的应用程序，单体服务可以更高效，因为没有跨服务的网络通信开销。
简单的调试和测试：由于应用程序的部分是紧密耦合的，单体服务通常更容易进行本地调试和单元测试。

缺点：

可扩展性：单体服务的可扩展性有限，通常需要垂直扩展（增加硬件资源）来处理更大的负载。
复杂性：随着应用程序的增长，单体服务往往变得庞大复杂，代码难以维护，理解和修改。
技术栈选择：随着时间的推移，可能会变得难以采用新技术，因为整个应用程序都依赖于特定的技术栈。
部署依赖性：单体服务的不同组件通常在部署时需要一起发布，因此一小部分代码的更改可能需要整个应用程序的重新部署。

微服务结构（Microservices Architecture）：

优点：

可扩展性：微服务允许水平扩展，每个服务都可以独立扩展，从而更好地应对高负载。
灵活性：不同的微服务可以使用不同的技术栈，这使得团队可以根据具体需求选择最合适的工具和框架。
分布式开发：微服务架构支持分布式开发，允许多个团队同时开发和部署各自的服务，提高了开发速度。
模块化和可维护性：每个微服务都是一个独立的模块，易于维护和修改，减少了代码库的复杂性。

缺点：

复杂性：微服务架构引入了分布式系统的复杂性，包括服务发现、负载均衡、故障恢复等问题。
部署和运维成本：微服务架构需要更复杂的部署和运维工作，包括监控、日志、安全等方面的工作。
一致性和事务管理：在分布式系统中确保一致性和事务管理可能更加复杂，需要额外的努力。
开发困难：微服务开发需要更高水平的团队协作和协调，因为不同的服务可能由不同的团队开发和维护。

总之，单体服务和微服务结构都有自己的优点和缺点。选择哪种架构取决于您的应用需求、团队的技能和组织的目标。有时候，混合使用两种架构也是一个有效的策略，根据具体的场景选择合适的架构。