Programming

Compiled for the Solutions Architect certification, from a Java backend perspective. Core idea: what pain point each service solves, when to choose it, and how to distinguish it from similar services. 1. Storage 1.1 Comparison of the three storage types Type Representative service Access unit Typical scenario Block storage EBS, EC2 Instance Store Block Databases, OS disks File storage EFS, FSx Files / directory tree Multi-instance sharing, NFS/SMB mounts Object storage S3 Object (Object + Key) Static assets, backups, data lakes Block storage → like a local hard drive; the OS sees a raw device it formats and mounts itself File storage → like a NAS; multiple machines can mount the same directory at once Object storage → like HTTP PUT/GET key-value; no directory concept, simulated with prefixes 1.2 Amazon S3 Quick reference of core features: ...

1. Service Decomposition and Remote Calls 1.1 Why decompose into services? As business grows, a monolith faces slow deployment, poor scalability, a frozen tech stack, and more. Microservices split it into small, independently deployable and scalable services, each responsible for a single business domain. Decomposition principles: Single responsibility: each service does one thing High cohesion, low coupling: tight within a service, loose between services Data independence: each service owns an independent database 1.2 The user-login flow (from a microservice view) Client → Gateway (auth) → business microservice A → microservice B (OpenFeign) ↓ Nacos (service discovery) 1.3 RestTemplate — the raw inter-service call RestTemplate is the HTTP client Spring provides for inter-service calls, but its code is verbose and it doesn’t support load balancing — a transitional solution before OpenFeign. ...

1. The Spring IoC Container 1.1 Container architecture BeanFactory (top-level interface) └── ApplicationContext (the commonly used interface, extends BF) ├── ClassPathXmlApplicationContext (XML config) ├── FileSystemXmlApplicationContext (filesystem-path XML) └── AnnotationConfigApplicationContext (annotation config) Core differences between BeanFactory and ApplicationContext: Feature BeanFactory ApplicationContext Bean init timing Lazy (on the first getBean) Eager (at container startup) Features Basic IoC IoC + event publishing + i18n + AOP, etc. Use case Extremely resource-constrained embedded 99% of business scenarios Why doesn’t ApplicationContext have close()? The ApplicationContext interface itself doesn’t define close(), to keep the interface general (not all containers can/need to be closed, e.g. web containers). But its implementation AbstractApplicationContext implements Closeable, so you can cast and call it, or receive it via the ConfigurableApplicationContext interface. ...

1. Introduction MyBatis-Plus (MP for short) is an enhancement tool for MyBatis. It only enhances MyBatis without changing it, built to simplify development and improve efficiency. Core features: Non-intrusive: adding MP has no effect on an existing MyBatis project — smooth as silk. Low overhead: basic CRUD is auto-injected at startup, with essentially no performance loss. Powerful CRUD operations: built-in generic Mapper and generic Service; with just a little configuration you get most single-table CRUD. Supports Lambda-style calls: write query conditions safely and efficiently via lambda expressions, preventing mistyped field names. Built-in code generator: generate Mapper, Service, Controller, etc. with minimal configuration. Built-in pagination plugin: physical pagination based on MyBatis; developers don’t need to worry about the details — just configure and use. Official site: https://baomidou.com/ ...