Spring Boot开端

KittyGuy
129 阅读6分钟

什么是微服务

  • 简而言之，微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个服务在自己的进程中运行， 并使用轻量级机制进行通信，通常是通过HTTP资源API。这些服务围绕着业务功能构建，并且可以通过完全自动化的部署机制独立部署。对这些服务的集中式管理最小化，它们可以使用不同的编程语言和数据存储技术编写。
  • 微服务架构风格的特点如下：
    • 将应用程序拆分为小型服务：应用程序被拆分为一组独立的、小型的服务单元，每个服务负责特定的业务功能。
      • 以游戏服务器为例，可以将服务简单拆分，登陆服务，战斗服务，统计和日志服务等。
    • 独立部署和扩展：每个微服务都可以独立地进行开发、部署和扩展，这提供了更大的灵活性和可伸缩性。
    • 轻量级通信机制：微服务之间使用轻量级的通信机制进行通信，通常是通过HTTP API进行交互。
    • 分散式治理：微服务的管理和治理被最小化，每个服务可以由独立团队负责开发和维护。
    • 多语言和多技术栈支持：每个微服务可以使用不同的编程语言和技术栈来实现，根据需求选择最适合的工具和技术。

快速构建一个Spring Boot项目

  • Spring Initializr image.png
  • 随便写点代码： 
    import org.springframework.http.MediaType;  
import org.springframework.web.bind.annotation.RequestMapping;  
import org.springframework.web.bind.annotation.RequestMethod;  
import org.springframework.web.bind.annotation.RestController;  

import java.util.Date;  

@RestController  
@RequestMapping(value = "api", produces = MediaType.APPLICATION_JSON_VALUE)  
public class FirstController {  
    @RequestMapping(value = "person", method = RequestMethod.GET)  
    public Object test() {  
       return new Person(1001, "KittyGuy", new Date());  
    }  

}  
record Person(int id, String name, Date birthday){  

}
    • 运行起来，浏览器访问一下： image.png
    • GMT：GMT通常在英国和一些英联邦国家中使用，尽管它已经被世界其他地方的标准所取代。
    • UTC：UTC是国际标准，被广泛接受和使用，特别是在计算机系统、航空航天和全球通信领域。

    总体而言，GMT可以视为UTC的前身，而UTC是一种更精确、更稳定并被广泛接受的国际时间标准。尽管GMT的概念仍然存在，但实际应用中，UTC已经成为了主要的时间标准。对于大多数人来说，GMT和UTC之间的差异可以忽略不计，因为它们在大多数情况下是相互等同的。

什么时候使用微服务

  • 复杂性管理：
    • 当应用程序变得庞大而复杂时，单体架构可能会导致开发、测试和部署变得困难。微服务架构通过将应用程序拆分为多个小型服务，每个服务专注于特定的业务功能，从而降低了系统的复杂性。
  • 高可伸缩性需求：
    • 如果你的应用程序需要处理大量的并发请求并需要快速扩展以满足用户需求，微服务架构可以提供更好的可伸缩性。由于每个微服务都是独立部署和扩展的，你可以针对具体的服务进行水平扩展，而不会影响整个应用程序。
  • 独立开发和部署：
    • 微服务架构允许团队独立开发、测试和部署各个服务。这种解耦性使得不同团队可以并行工作，加快了开发周期，并且不会因为一个服务的修改而影响到其他服务。
  • 技术异构性：
    • 如果你的应用程序需要使用不同的技术栈和工具来满足不同的业务需求，微服务架构可以提供灵活性。每个微服务可以使用最适合的技术来解决特定的问题，而不需要整个应用程序都使用相同的技术栈。
  • 高可用性和容错性：
    • 微服务架构可以提高系统的可用性和容错性。当一个服务发生故障时，其他服务仍然可以正常运行，避免了整个应用程序的崩溃。此外，通过使用负载均衡和故障转移机制，可以在出现故障时自动路由请求到可用的服务上。

什么时候不用微服务

  • 小规模应用程序：
    • 如果你的应用程序相对较小且简单，没有复杂的业务逻辑或高并发需求，采用微服务架构可能会增加不必要的复杂性和开发成本。在这种情况下，使用传统的单体架构可能更加合适。
  • 频繁的通信和网络开销：
    • 微服务架构中的不同服务通过网络进行通信，这会增加一定的延迟和网络开销。如果你的应用程序需要频繁地进行大量的服务间通信，这可能会对性能产生负面影响。在这种情况下，使用单体架构可能更加高效。
  • 数据一致性要求高：
    • 在微服务架构中，每个微服务通常都有自己的数据存储。如果你的应用程序需要维护高一致性的数据模型，并且需要跨多个服务进行复杂的事务处理，微服务架构可能会增加处理数据一致性的复杂性。
  • 成本和运维考虑：
    • 微服务架构涉及多个服务的部署、管理和监控。这可能增加了部署和运维的成本。如果你的组织没有足够的资源或预算来支持微服务架构的复杂性，使用单体架构可能更加经济实惠。

如何构建微服务

  • 定义服务边界：
    • 首先，确定应用程序中的不同业务功能，并确定如何将它们划分为独立的服务。这需要对业务进行分析和拆解，以便将应用程序拆分为更小、更可管理的服务。
  • 设计服务接口：
    • 为每个服务定义清晰的接口，以确定服务之间的通信方式和数据交换格式。常见的接口设计方法包括使用RESTful API、消息队列、事件驱动等。
  • 确定服务技术栈：
    • 选择适合每个服务的技术栈和编程语言。根据服务的需求和团队的技术能力，选择合适的框架、库和工具来实现每个服务。
  • 管理服务之间的通信和协调：
    • 确保服务之间的通信和协调是可靠和高效的。使用适当的通信协议、消息队列、服务注册和发现机制等来实现服务之间的协作和集成。
  • 高可用性和容错性：
    • 考虑使用负载均衡、故障转移和容器编排等机制来提高微服务架构的可用性和容错性。确保在服务故障或不可用时仍能提供稳定的服务。
avatar
文章
阅读
粉丝