### Account Center Interface Services Overview Source: https://github.com/zealon159/light-reading-cloud/blob/master/README.md This section provides an overview of the interface services exposed by the 'reading-cloud-account' module. These services primarily handle user authentication, including login and registration, as well as user-specific behaviors such as managing bookshelves and liked content. ```APIDOC Account Center Interface Services: - User Service: - Purpose: Handles user login authentication and registration processes. - User Bookshelf Service: - Purpose: Manages user's personal book collections and related operations. - User Like See Service: - Purpose: Manages user's preferences for liked or seen content. ``` -------------------------------- ### Book Center API: book/chapter/readChapter Logic Source: https://github.com/zealon159/light-reading-cloud/blob/master/README.md Describes the logic for the `book/chapter/readChapter` interface, which provides efficient chapter navigation. It leverages a pre-calculated linked-list structure stored in Redis Hash to avoid repeated database queries for previous and next chapters. The process involves a one-time database query and cache population if data is not found in Redis, followed by direct Redis lookups for subsequent requests. ```APIDOC API Endpoint: `book/chapter/readChapter` Purpose: Provides current chapter content along with pre-calculated previous and next chapter IDs for efficient navigation. Data Structure: `BookPreviousAndNextChapterNode` (internally) Storage: Redis Hash (Key: Chapter ID, Value: Linked-list node data) Implementation: `BookChapterServiceImpl.getChapterNodeData` Flow: 1. Client requests `book/chapter/readChapter` with current chapter ID. 2. Service checks Redis cache for chapter node data. 3. If not in cache (blue path in diagram): a. Query database for chapter details. b. Calculate the entire chapter linked-list for the book. c. Store the linked-list in Redis Hash. 4. If in cache (or after caching): a. Retrieve chapter node data from Redis (O(1) complexity). b. Return current chapter content and pre/next chapter IDs (not full content) to client. ``` -------------------------------- ### Account Center Data Table Structures Source: https://github.com/zealon159/light-reading-cloud/blob/master/README.md This documentation describes the core data table structures for the 'reading-cloud-account' microservice, which manages user-related functionalities. It includes tables for user profiles, user bookshelves, and user-liked content, forming the foundation for user data management. ```APIDOC Account Center Data Tables: - User Table (user): Stores user profile information. - User Bookshelf Table (user_bookshelf): Manages books added to a user's personal bookshelf. - User Like See Table (user_like_see): Records content that a user has marked as 'liked' or 'seen'. ``` -------------------------------- ### Homepage Center API and Data Design Source: https://github.com/zealon159/light-reading-cloud/blob/master/README.md Documents the data tables and API logic for the homepage service, which provides app homepage data, including banners and book lists. It details the configuration tables for different page types and the process for loading content, handling random book retrieval, and utilizing FeignClient for inter-service communication with caching considerations. ```APIDOC Homepage Center Data Tables: - `index_page_config`: Main configuration for homepage sections (banner/booklist) by `page_type` (1=booklist, 2=banner). - `index_banner`: Banner carousel configuration. - `index_banner_item`: Banner carousel details. - `index_booklist`: Book list configuration. - `index_booklist_item`: Book list item details. Homepage Center API Logic (`getIndexPageByType`): Purpose: Dynamically loads configured sections (banners/booklists) for the app homepage. Features: - Ordered loading of sections based on configuration. - Support for different booklist display styles. - Options for 'change' or 'more' functionality for booklists. - Random book retrieval with uniqueness constraints (no repeats within a session, no repeats with client-side books). Implementation: `cn.zealon.readingcloud.homepage.service.impl.IndexPageConfigServiceImpl.java` Inter-service Communication: Method: FeignClient (for calls to Book Center and Account Center). Recommendation: Implement caching for remote calls if 100% real-time data is not required, to reduce pressure on service providers. ``` -------------------------------- ### Search Service Implementation and Data Synchronization Methods Source: https://github.com/zealon159/light-reading-cloud/blob/master/README.md This section outlines the architecture of the search service, based on ElasticSearch 6.3.1 and using Jest as a client. It discusses two primary methods for data synchronization: traditional scheduled tasks (CRON) and a more real-time approach using Message Queues (MQ), specifically RabbitMQ, highlighting the advantages and disadvantages of each. ```System Design Search Service: - Based on ElasticSearch 6.3.1 - Client: Jest Data Synchronization Methods: 1. Scheduled Tasks (CRON): - Description: Incremental sync scripts executed at specified intervals. - Pros: Simple, traditional. - Cons: Data not timely, potential CPU waste if no data. 2. Message Queue (MQ) based (e.g., RabbitMQ): - Description: Used for decoupling, peak shaving, and asynchronous processing. - Process: Write operation on data -> Send data to specified queue (RabbitMQ exchange/queue) -> Consumer service listens and processes data -> Synchronize data to ES index. - Pros: Near real-time updates, improved system responsiveness. ``` -------------------------------- ### JSON Data Structure for Book Chapter Navigation Source: https://github.com/zealon159/light-reading-cloud/blob/master/README.md This JSON snippet illustrates the linked-list-like data structure used to store book chapter relationships. Each object represents a chapter, with 'pre' and 'next' arrays pointing to its preceding and succeeding chapters, enabling efficient O(1) navigation when stored in Redis Hash. ```JSON [ { "key":"519", "value":{ "id":529, "name":"第一章 装B的乞丐", "pre":null, "next":[ { "id":530, "name":"第二章 资格" } ] } }, { "key":"530", "value":{ "id":530, "name":"第二章 资格", "pre":[ { "id":529, "name":"第一章 装B的乞丐" } ], "next":[ { "id":531, "name":"第三章 开始修炼清心诀" } ] } }, { "key":"530", "value":{ "id":531, "name":"第三章 开始修炼清心诀", "pre":[ { "id":530, "name":"第二章 资格" } ], "next":[ { "id":532, "name":"第四章 暴打恶霸" } ] } } ] ``` -------------------------------- ### Spring Cloud Gateway Core Concepts and Authentication Source: https://github.com/zealon159/light-reading-cloud/blob/master/README.md Documents the core components of Spring Cloud Gateway, including Predicates for routing and Filters for request processing. It highlights the implementation of a custom global filter (AuthFilter) for unified authentication, whitelist management via Nacos, and dynamic routing configuration using YAML. ```APIDOC Spring Cloud Gateway: Core Components: - Predicate: Route matching rules. - Filter: Request processing filters (e.g., authentication, logging). Authentication Implementation: - Custom Global Filter: `cn.zealon.readingcloud.gateway.filter.AuthFilter` - Handles whitelist bypass. - Performs authentication validation. - Dynamically processes request parameters. - Whitelist Configuration: Managed dynamically via Nacos. Routing Configuration: - Method: YAML-based configuration (e.g., in `reading-cloud-gateway` project). ``` -------------------------------- ### Microservice Security Authentication with JWT Source: https://github.com/zealon159/light-reading-cloud/blob/master/README.md This documentation details the security authentication mechanism adopted for the microservice architecture, focusing on JSON Web Tokens (JWT). It compares JWT with traditional methods like Session and HTTP Basic Authentication, explaining why JWT is preferred for microservices and outlining its typical flow from token generation to gateway-level validation. ```APIDOC Security Authentication Methods Comparison: - Session: - Mechanism: Server stores user info, client uses Cookie (SessionId). - Use Case: Traditional web applications. - HTTP Basic Authentication: - Mechanism: Client sends Base64 encoded username:password in Authorization header. - Use Case: Simple API authentication. - Token (JWT): - Mechanism: Token contains encrypted user info, server decrypts. - Use Case: Preferred for microservices due to statelessness and scalability. JWT (JSON Web Token) Authentication Flow: 1. User provides credentials (username, password) to authentication server. 2. Server validates credentials; if successful, generates and returns a JWT to the client. 3. Client stores the received JWT. 4. For subsequent requests, the client includes the JWT (typically in the Authorization header). 5. Gateway intercepts the request and validates the JWT: - If valid: Request is forwarded to the appropriate backend service, often with parsed user information from the token. - If invalid: An error response is returned directly to the client. Key Considerations: - Microservice internal requests typically do not require re-authentication (handled by gateway). - Whitelisting can be used at the gateway for services that do not require authentication. - Caching JWTs can significantly improve gateway CPU performance by reducing repeated encryption/decryption operations. ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.