读书笔记《cloud-native-applications-in-java》云简介-本地云
云计算的出现和移动设备的普及导致重新定义了整个客户体验的面向消费者的公司（如亚马逊、Netflix、优步、谷歌和 Airbnb）的兴起。这些公司已经在云上构建了他们的应用程序（Web 和移动界面），使用的功能或服务允许他们根据需求进行扩展或缩减，随时可用，并准备好处理所有级别的故障。
传统企业正在关注这些面向消费者的公司，并希望采用他们的一些最佳实践。他们这样做是为了帮助扩展快速发展的企业应用程序，使他们能够利用云的弹性和可扩展性。
在深入探讨云原生之前，让我们看看本章的内容。我们将在本章中介绍以下主题：
- Why go cloud-native?
- What is cloud-native?
- Intro to the 12-factor app
- Why move from monolithic applications to distributed microservice-based applications?
- The advantages of building a distributed microservice-based application
让我们看一下以下几点来理解为什么我们需要去云原生：
- The first wave of cloud adoption was about cost savings and business agility (especially around infrastructure provisioning and cheap storage). With increasing cloud adoption, enterprises started discovering Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) services and their utilization in building applications that leverage the elasticity and scalability of the cloud, all the while embracing the inherent failures of the cloud platform.
- A lot of enterprises are adopting greenfield design and development of microservices in the area of digital initiatives. When dealing with the Internet of Things (IoT), mobile devices, SaaS integration, and online business models, enterprises are working with niche players in the market. These new age business models are being designed and developed as a system of innovation on the enterprise end. The models are iterated rapidly to identify and bubble up the customer's needs, their preferences, what works, and what does not work.
- Enterprises are also developing digital services based on their product lines. The products are enhanced with IoT to enable them to emit data about the products' performance. The data is collated and analyzed for patterns such as predictive maintenance, usage models, and external factors. The data from customers is collated and aggregated to build newer models for product enhancements and new features. A lot of these new digital services use the cloud-native model.
- These modern digital solutions use APIs from various providers, such as Google Maps for location, Facebook/Google for authentication, and Facebook/Twitter for social collaborations. Mashing all these APIs with the features and functionality of enterprise business allows them to build a unique proposition for the customer. All of this integration is happening at the API level. The mobile application is not meant for tens of hundreds of users, but tens of millions of users. This means that, as the load increases, the underlying application functionality should be able to scale up to provide a seamless experience to the customer.
- One way to scale up the resources for the enterprise is to do the heavy lifting in terms of service/environment provisioning as the load goes up or in case of failures. Another way is to offload the heavy lifting of the underlying services to the cloud platform provider. This is the sweet spot where building cloud-native applications that make use of the cloud provider's platform services allows the enterprise to offload the key aspects of scalability and focus on value generation parts.
当应用程序被设计和架构以利用云计算平台支持的底层IaaS和PaaS服务时，它们被称为云原生应用程序。
这意味着构建可靠的系统应用程序，例如在三个 9 (99.9%) 基础架构和应用程序组件上运行的五个 9 (99.999%)。我们需要设计我们的应用程序组件来处理故障。为了处理此类故障，我们需要一种结构化的可扩展性和可用性方法。为了支持整个应用程序规模，所有部分都需要自动化。
云采用通常发生在一系列步骤中，企业在开始构建云原生应用程序之前就开始探索服务。采用始于将开发/测试环境迁移到云端，其中快速配置是来自业务和开发人员社区的关键问题。一旦企业通过了环境配置阶段，下一步/模型将在以下部分中讨论企业应用程序迁移到云原生模型的步骤/模型。
传统上，企业开始使用 IaaS 服务开始他们的云计算之旅。他们将业务应用程序工作负载从本地数据中心转移到云端computing 平台。这是第一波采用云计算平台，企业从资本支出模式转变为运营支出模式。
顾名思义，IaaS 专注于基础设施——计算节点、网络和存储。在此模型中，企业可以利用云的弹性，可以根据传入的需求或负载添加或删除计算节点。 虚拟机（VM）抽象出底层 硬件，只需单击几下即可增加或减少虚拟机的数量。
企业通常在第一波浪潮中使用 IaaS，原因如下：
- Variability of resources: The ability to add/remove resources at will, which in turn allows more business agility
- Utility model: IaaS provides basic resources that are rented out on an hourly basis, allowing more predictability and an opex model
一旦企业开始对 IaaS 感到满意，下一波采用就是将 PaaS 用作应用程序工作负载的一部分。在这个阶段，企业开始发现具有以下好处的服务：
- Platform services replacement: This involves the identification of potential platform features of the enterprise, lifting and shifting the workload, and replacing it with equivalent platform services from the cloud provider. For example:
- Replacing application messaging systems with queuing systems provided by the cloud provider (such as AWS SQS)
- Replacing data stores or relational database management systems (RDMBS) with equivalent managed data services (such as AWS RDS)
- Replacing security or directory services with a managed directory or security services (such as AWS Directory and AWS IAM)
- These services allow the enterprise to do away with all the operational efforts, such as data store backup, availability, scalability, and redundancy, and replace them with a managed service that provides all these features
- Application services replacement: Enterprises discover new services that can replace their own platform or utility services. For example:
- Replacing build and release services or products with equivalent DevOps services from the cloud provider (such as AWS CodePipeline, AWS CodeCommit, or AWS CodeDeploy)
- Replacing application services or products with equivalent application platform services (such as AWS API Gateway, AWS SWF, and AWS SES)
- Replacing analytics workload services with equivalent application analytics services (such as AWS Data Pipeline and AWS EMR)
一旦应用程序开始采用平台服务，应用程序就开始抽象 商业现货（COTS）产品（例如消息、通知、安全、工作流和 API 网关）并将它们替换为等效的功能平台服务。例如，不是托管和运行消息传递 IaaS，而是迁移到等效平台服务意味着迁移到一个模型，您只需为发送的消息数量付费，而不会产生任何额外的运营成本。当您从租用和运营产品转变为仅在使用时租用产品的模式时，这种模式带来了显着的节省。
要启用 IaaS 和 PaaS 服务的采用，需要对应用程序的设计和架构方式进行更改。
在基础平台（阅读：应用服务器）上设计企业应用程序的模型意味着应用程序的可扩展性和可用性的繁重工作是平台的责任。企业开发人员将专注于使用标准化的 JEE 模式和开发组件（演示、业务、数据和集成）来构建功能齐全的事务性应用程序。应用程序的扩展程度受到底层平台能力（节点集群和分布式缓存）的限制：
单片应用
构建为单体应用程序的业务应用程序通常具有以下特征：
- The entire application logic is packaged into a single EAR file
- The application reuse is derived by sharing JARs
- Application changes are planned months in advance, typically in a big push once a quarter
- There is one database that encompasses the entire schema for the application
- There are thousands of test cases that signify the amount of regression
- The application design, development, and deployment requires coordination among multiple teams and significant management
随着社交互动和移动用户的出现，应用程序用户和数据的规模开始呈指数级增长。企业很快发现，平台正在成为以下问题的瓶颈：
- Business agility: The operational cost of managing the application platform and making constant changes to the features/functionalities was getting hampered because of the monolithic nature of the application. Even for a small feature change, the entire cycle of regression tests and deployment across server clusters was eating into the overall speed of innovation. The mobile revolution meant that the problem was not just at the channel layers, but also percolated down to the integration and systems of record layers. Unless enterprises fixed the problem across these layers, the ability to innovate and be competitive in the market would be under threat.
- Cost: To handle the increased demand, the IT Operations team were adding new server instances to handle the load. However, with each new instance, the complexity was increasing along with license costs (that depended on the number of cores). Unlike the Facebooks of the world, enterprise cost per user was increasing with every user acquisition.
此时，企业开始关注开源产品，以及如何在面向消费者的公司中构建现代应用程序，为数百万用户提供服务、处理 PB 级数据并部署到云中。
面向消费者的公司在其生命周期的早期就会遇到这些障碍。许多创新导致了新开源产品的设计和开发，以及云计算的设计模式。
在这种背景下，面向服务的架构（SOA ) 进行了研究和企业调查了应用程序架构如何采用设计独立、离散、并且可以与其他服务集成和组合。这导致了微服务模型的兴起，它与云服务模型很好地适应和集成，在云服务模型中，一切都可以作为服务和 HTTP 端点使用。
微服务是面向服务架构 (SOA) 的一种专门化和实现方法，用于构建灵活、可独立部署的软件系统
– 维基百科
设计和开发微服务，记住可以通过组合这些服务来构建业务应用程序。微服务是围绕以下原则设计的：
- Single-responsibility principle: Each microservice implements only one business responsibility from the bounded domain context. From a software point of view, the system needs to be decomposed into multiple components where each component becomes a microservice. Microservices have to be lightweight, in order to facilitate smaller memory footprints and faster startup times.
- Share nothing: Microservices are autonomous, self-contained, stateless, and manage the service state (memory/storage) through container-based encapsulation models. The private data is managed by a service and there is no contention on the data from any other service. Stateless microservices scale better and start faster than stateful ones, as there is no state to be backed up on shutdown or activated on startup.
- Reactive: This is applicable for microservices with concurrent loads or longer response times. Asynchronous communication and the callback model allow optimal utilization of the resources, resulting in better availability and increased throughput of the microservices.
- Externalized configuration: This externalizes the configurations in the config server, so that it can be maintained in hierarchical structure, per environment.
- Consistent: Services should be written in a consistent style, as per the coding standards and naming convention guidelines.
- Resilient: Services should handle exceptions arising from technical reasons (connectivity and runtime), and business reasons (invalid inputs) and not crash. Patterns, such as circuit breakers and bulk headers, help isolate and contain failures.
- Good citizens: Microservices should report their usage statistics, the number of times they are accessed, their average response time, and so on through the JMX API or the HTTP API.
- Versioned: Microservices may need to support multiple versions for different clients, until all clients migrate to higher versions. There should be a clear version strategy in terms of supporting new features and bug fixing.
- Independent deployment: Each of the microservices should be independently deployable, without compromising the integrity of the application:
从单体应用程序迁移到基于微服务的应用程序
后续章节将详细介绍微服务的设计、开发和部署注意事项。我们将了解如何为电子商务产品构建服务。相信大家对电子商务都比较熟悉，很容易理解产品需求。
为了构建一个可以跨云提供商部署的分布式、基于微服务的应用程序，Heroku 的工程师提出了 12 个需要实施 任何现代云原生应用程序：
- Single codebase: The application must have one codebase, tracked in revision control for every application (read: microservice) that can be deployed multiple times (development, test, staging, and production environments). Two microservices do not share the same codebase. This model allows the flexibility to change and deploy services without impacting other parts of the application.
- Dependencies: The application must explicitly declare its code dependencies and add them to the application or microservice. The dependencies are packaged as part of the microservice JAR/WAR file. This helps isolate dependencies across microservices and reduce any side effects through multiple versions of the same JAR.
- Config: The application configuration data is moved out of the application or microservice and externalized through a configuration management tool. The application or microservice will pick up the configuration based on the environment in which it is running, allowing the same deployment unit to be propagated across the environments.
- Backing services: All external resources, access should be an addressable URL. For example, SMTP URL, database URL, service HTTP URL, queue URL, and TCP URL. This allows URLs to be externalized to the config and managed for every environment.
- Build, release, and run: The entire process of building, releasing, and running is treated as three separate steps. This means that, as part of the build, the application is built as an immutable entity. This immutable entity will pick the relevant configuration to run the process based on the environment (development, testing, staging, or production).
- Processes: The microservice is built on and follows the shared-nothing model. This means the services are stateless and the state is externalized to either a cache or a data store. This allows seamless scalability and allows load balance or proxy to send requests to any of the instances of the service.
- Port binding: The microservice is built within a container. The service will export and bind all its interfaces through ports (including HTTP).
- Concurrency: The microservice process is scaled out, meaning that, to handle increased traffic, more microservice processes are added to the environment. Within the microservice process, one can make use of the reactive model to optimize the resource utilization.
- Disposability: The idea is to build a microservice as immutable with a single responsibility to, in turn, maximize robustness with faster boot-up times. Immutability also lends to the service disposability.
- Dev/prod parity: The environments across the application life cycle—DEV, TEST, STAGING, and PROD—are kept as similar as possible to avoid any surprises later.
- Logs: Within the immutable microservice instance, the logs generated as part of the service processing are candidates for state. These logs should be treated as event streams and pushed out to a log aggregator infrastructure.
- Admin processes: The microservice instances are long-running processes that continue unless they are killed or replaced with newer versions. All other admin and management tasks are treated as one-off processes:
12 因素应用程序
遵循这 12 个因素的应用程序对外部环境不做任何假设，允许它们部署在任何云提供商平台上。这允许跨环境运行相同的工具/流程/脚本集，并以一致的方式部署分布式微服务应用程序。
为了成功运行微服务，需要某些启用 组件/服务。这些支持服务可以标记为支持微服务的构建、发布、部署和运行所需的 PaaS。
在云原生模型的情况下，这些服务available作为来自云提供商本身的 PaaS 服务：
- Service discovery: When the application is decomposed into a microservices model, a typical application may be composed of hundreds of microservices. With each microservice running multiple instances, we soon have thousands of microservice instances running. In order to discover the service endpoint, it is pertinent to have a service registry that can be queried to discover all of the instances of the microservice. In addition, the service registry tracks the heartbeat of every service instance to make sure that all services are up and running. Further, the service registry helps in load balancing the requests across the service instances. We can have two models for load balancing:
- Client-side load balancing:
- A service consumer asks the registry for a service instance
- The service registry returns with the list of services where the service is running
- Server-side load balancing:
- The service endpoint is hidden by Nginx, API Gateway, or another reverse proxy from the consumer
该领域的典型产品是 Consul 和 Zookeeper：
- Client-side load balancing:
服务注册表
- Config server: The microservice needs to be initialized with multiple parameters (for example, database URL, queue URL, functional parameters, and dependency flags). Managing properties in file or environment variables beyond a certain number can become unwieldy. To manage these properties across environments, all such configurations are managed externally in a configuration server. At boot time, microservices will load the properties by invoking the API on the config server. Microservices also make use of listeners to listen for any changes to the properties on the config server. Any runtime change of properties can be picked up immediately by the microservices. The properties are typically categorized at multiple levels:
- Service-specific properties: Hold all properties tied to the microservice
- Shared properties: Hold properties that might be shared between services
- Common properties: Hold properties that are common across services
配置服务器可以在源代码控制系统中备份这些属性。该领域的典型产品有 Consul、Netflix Archaius 和 Spring Cloud Config server：
配置服务器
- Service management/monitoring: An average business application typically tends to get decomposed into about 400 microservices. Even if we ran two to three instances of these microservices, we would be talking about managing over 1,000 instances of our microservices. Without an automated model, managing/monitoring these services becomes an operational challenge. The following are the key metrics that need to be managed and monitored:
- Service health: Each service needs to publish its health status. These need to be managed/tracked to identify slow or dead services.
- Service metrics: Each service also publishes throughput metrics data, such as the number of HTTP requests/responses, the request/response size, and the response latency.
- Process info: Each service will publish JVM metrics data (like heap utilization, the number of threads, and the process state) typically available as part of the Java VisualVM.
- Log events as stream: Each service can also publish log events as a set of streaming events.
所有这些信息都从服务中提取并捆绑在一起以管理和监视应用程序服务环境。需要进行两种类型的分析——事件相关性和纠正决策。警报和执行服务是作为服务监控系统的一部分构建的。例如，如果需要维护一定数量的服务实例并且数量减少（由于健康检查而导致服务不可用），那么驱动服务可以将该事件作为指示器来添加相同服务的另一个实例。
此外，为了通过微服务模型跟踪服务调用流，有可用的第三方软件可以帮助创建识别的请求并跟踪服务调用如何通过微服务流动。该软件通常将代理部署到容器上，容器将它们编织到服务中并跟踪服务指标：
服务指标
- Container management/orchestration: Another key infrastructure piece of the microservice environment is container management and orchestration. The services are typically bundled in a container and deployed in a PaaS environment. The environment can be based on an OpenShift model, a Cloud Foundry model, or a pure VM-based model, depending whether they are deployed on a private or a public cloud. To deploy and manage the dependencies between the containers, there is a need for container management and orchestration software. Typically, it should be able to understand the interdependencies between the containers and deploy the containers as an application. For example, if the application has four pieces—one for UI, two for business services, and one for data store—then all of these containers should be tagged together and deployed as a single unit with interdependencies and the right order of instantiation injected.
- Log aggregation: 1 of the 12 factors is treating logs as event streams. The containers are meant to be stateless. The log statements are typically stateful events that need to be persisted beyond the life of the containers. As a result, all logs from the containers are treated as event streams that can be pushed/pulled onto a centralized log repository. All the logs are aggregated and various models can be run on these logs for various alerts. One can track security and failure events through these logs, which can feed into the service management/monitoring system for further actions:
日志聚合
- API Gateway/management: The services are meant to be simple and follow the single responsibility model. The question arises: who will handle other concerns, such as service authentication, service metering, service throttling, service load balancing, and service freemium/premium models? This is where the API Gateway or management software comes into the picture. The API Gateway handles all such concerns on behalf of the microservice. The API Gateway provides multiple options for managing the service endpoints and can also provide transformation, routing, and mediation capabilities. The API Gateway is more lightweight, compared to the typical enterprise service bus.
API 管理网关
- DevOps: Another key aspect is the continuous integration/deployment pipeline, coupled with the automated operations that need to set up the microservice-based applications. As the developer writes code, it goes through a series of steps that need to be automated and mapped with gating criteria to allow the release of regression-tested code:
开发生命周期
企业 中的微服务采用受数字化转型的共同主题驱动，无论他们是否希望重新构建现有的单体架构创新系统中的应用程序，以提高业务敏捷性并减少技术债务，或开发新的应用程序，使他们能够快速创新并尝试不同的业务模型。
企业一直在运行基于 JEE 原则在应用服务器集群上运行的通道 applications。这些应用程序多年来积累了大量的技术债务，并已成为一个主要问题——庞大、笨重且难以持续变化。
随着商业环境竞争的加剧和渠道的扩散，企业正在寻求更快的创新并提供无缝的客户体验。另一方面，他们不想放弃对现有应用程序的现有投资。
在这种情况下，企业正在执行多个计划，以将现有应用程序重构和重新架构为现代、分布式、基于微服务的模型，这些模型提供快速迭代的货币并且是面向未来的。
企业正以两管齐下的方式解决这个问题：
- Setting the base platform that provides the core ecosystem as a set of services to deploy and run the microservices. These services include Configuration Management, Service Discovery, Elastic Compute, Container Management, Security, Management and Monitoring, DevOps pipeline, and more. Enterprises typically weigh in between using the public cloud and setting up a private cloud. The choice of cloud platform depends on the industry in question and the maturity of the enterprise strategy.
- The second approach is to chip at the monolithic application, one functional piece at a time, and migrate the core business logic to the microservice model. The GUI part is separately migrated to an SPA model using frameworks such as AngularJS and ReactJS. For example, a lot of e-commerce enterprises have moved their catalogue and search services to elastic cloud providers. Only when the customer clicks the checkout do they bring the customer to the in-house data center.
一旦企业在平台服务方面建立了生态系统，添加更多基于微服务的功能的能力就变得容易，从而在业务敏捷性和创新方面提供所需的动力。
我们将在 第 12 章中更详细地介绍数字化转型，数字化转型。
在本章中，我们介绍了云原生编程是什么以及为什么要这样做。当谈到云原生应用程序时，我们看到了企业的各种采用模型。我们涵盖了分布式应用程序的 12 个因素，以及使用基于微服务的设计来支持云原生。我们介绍了用于构建基于微服务的应用程序的支持生态系统。
随着本书的深入，我们将介绍如何设计、构建和运行您的云原生应用程序。我们还将介绍使用两个云提供商平台（AWS 和 Azure）的云原生应用程序开发。我们将利用他们的平台服务来构建云原生应用程序。
我们还将介绍云原生应用程序的运营方面——DevOps、部署、监控和管理。最后，我们将介绍如何将现有的单体应用程序转变为现代分布式云原生应用程序。在下一章中，我们将直接创建我们的第一个云原生应用程序。