何謂微型服務？

Microservices would not be as effective an approach if it weren’t for containers. Much like virtual machines, containers are a form of virtualization, but whereas VMs virtualize the hardware, allowing multiple operating systems to run concurrently on the same hardware, containers virtualize the OS, allowing multiple workloads to run on a single instance of an operating system.

Virtualization is the act of dividing up computational resources (CPU, RAM, storage, connectivity) and wrapping them into individual scopes. To these virtual spaces, they believe they are a real, full system, unaware they are just a part of a larger machine. This allows multiple environments to run on the same hardware, and is the fundamental makeup of the cloud space, allowing multiple users to access a cloud system that may be running many more environments than the physical infrastructure would seem to support.

Virtualization, using either VMs or containers, contributes to IT flexibility, agility, and scalability, however, containers are aptly suited for microservices. Compared to VMs, containers are much smaller because they virtualize at the user level. A container contains a package of software, with the necessary dependencies, including code, runtime, configuration, and system libraries for it to be able to run on a host. Container instances sit atop a container engine that orchestrates the creation of containers, their resource allocations, and manages them. In this way, a container can be created from an image, holding and running a microservice, giving it exactly the resources it needs, and finally can blink out of existence instantaneously when it’s no longer needed. Has the microservice failed to require it to be reset? Simply spin up a new container, and discard the failed one. Additional workloads press the system, responsive automatic scaling can duplicate containers to meet demand. Containers are light-weight and compared to VMs or a server reboot can multiply and collapse nearly instantly.

Microservices running within containers is the preferred method. The ephemeral nature and size of containers match the size and flexibility needed for microservices. Managing containers is best performed through automation.

Docker and Kubernetes are the two most popular tools for containerizing microservices. Docker is concerned with creating containers, and Kubernetes is concerned with container orchestration, the automatic management of individual containers within clusters. Microservices and containers work so well together that they seem to be made for each other, however, microservices are not container dependent and can run in different environments. In each microservice scenario without containers, there are resource inefficiencies.

• Single Virtual Machine Environment Running Each Microservice — Like a container, each microservice has its own unique runtime environment. But this is a virtual machine instance with its own OS and allocated system resources, consuming much more of the system than containers. From a business standpoint, the OS may be limited by license, and each instance may require a subscription.
• Single Operating System Environment Running Many Microservices — Microservices are no longer encapsulated and separated from other microservices, complicating automation. This easily can lead to dependency conflicts between libraries, and if one microservice fails prompting a restart, every service goes down.
• One Physical Server Per Microservice — While this contains the microservice in a single environment, the hardware overkill makes this approach simply undesirable.

With all the benefits and advantages that make microservices and containers attractive, it does come with its own set of challenges. Many on this list emerge from new complexities and ways of thinking about application development, by understanding and planning for them, many can be mitigated.

• Single Concern Bounded Context — The single concern principle for microservices dictates that a microservice must only have one concern. Therefore API calls are used between microservices so that a microservice can guarantee its own integrity, mutability, and separation. Understanding the boundaries of concern entails developers understanding the overall context for which the microservice exists. The more the whole is broken down into microservices, the more dependencies and complexity there is.
• Dynamic Vertical and Horizontal Scaling — Scaling resources to meet demands is a complex operational challenge best automated. Measuring performance though is a sure way to understand how the overall system needs to scale. Consider which microservices are most essential, unlike a monolith system where resources are assigned to the app, these essential microservices may need to scale together all at the same time, posing coordination challenges.
• Microservices Monitoring — Microservices essentially break functionality down into component parts, while in one way simplifying some aspects, it often convolutes data paths between components, which makes monitoring difficult or impossible.
• Fault Tolerance — Container encapsulation provides capabilities that assist in building fault- tolerant systems. Without these safeguards, such as the ability to launch containers on different machines, using microservices may work against the system, such as in cascading failures.
• Dependency Chain — Code within microservices may become simpler for developers to maintain, but, the dependency chain can quickly grow longer, or wider due to the fact that microservice dependencies are indirect rather than explicit, as in monolith code. Visualizing a dependency graph, and automating coupling discovery—coupling is when two microservices are linked too closely and should be reconsidered for refactoring—are two good methods for understanding dependencies and where they may likely cause problems.
• DevOps Culture — DevOps processes and practices are perfect for taking advantage of microservices and containers, however, shifting from monolithic development lifecycles to that of agile may prove challenging for some teams.

Managing and monitoring microservices requires the right tools. Teams can choose between forming a toolbox of apps that each help visualize an aspect of the whole system, such as using the information from a network monitoring app, a container monitoring app, and a log monitoring app to form a picture.

Another option is using an observability solution suite, which could be a single app or combination of products. These tools provide single-pane-of-glass visibility across the organization's infrastructure, applications, services, and cloud. These options must provide the following core capabilities:

• Performance monitoring of web applications, cloud applications, and/or services
• Data visualizations of application and cloud infrastructure performance metrics
• Performance baselining
• Mechanisms for ensuring best practices
• Multiple systems monitoring capabilities
• User experience monitoring
• Database(s) monitoring
• Container, application, and network performance tracking
• Real-time monitoring analytics