I believe everyone is familiar with the monolithic architecture. It corresponds to the early mainframe era. At that time, we expected to use a machine with very good performance to carry all parts of the program, such as database and business logic. However, this architecture is not only complex in code, but also complex in calling each other, and it is also difficult to modify.
Later, in order to facilitate the interaction between functions, a layered architecture was proposed. The code in this architecture is divided into a presentation layer, a business logic layer, a data persistence layer, and a database layer.
Later, a service-oriented SOA architecture was developed. The so-called service refers to a single functional unit that can be accessed remotely and independently executed and updated, such as online retrieval of credit card bills. The basic principle of this architecture is to be independent of vendors, products, and technologies, and through communication protocols on the network, application components provide services to other components. SOA has limitations in the technical architecture. Although all services have been decoupled, deployment is still together and maintenance is still troublesome.
The next thing that appears is the familiar microservice architecture, which divides a single application into a set of small services, loosely coupled between services, and uses lightweight communication protocols (RPC/REST) for inter-service communication. The biggest difference between the microservice architecture and the SOA architecture is that it can be deployed independently. The benefits of these features are not only faster online, but also because of the use of communication protocols between services, so the technology can be heterogeneous. In addition, from the perspective of application architecture, its scalability and scalability are also very good, and it also has a good feature API first, which makes the architecture very friendly to mobile applications.
Note: In addition to these typical architectures, there are microkernel architectures and event-driven architectures, which will not be introduced here. Readers can check Oreilly's "Software Architecture Patterns".
Infrastructure evolution
In the early stages of infrastructure evolution, mainframes were used first, and then x86 minicomputer servers. Until this stage, the cost of infrastructure is still very high, so virtualization and cloudification will be developed later. Cloudization enables infrastructure to be outsourced, reducing costs and ensuring maintainability. At the same time, cloud services are usually programmable and easier to automate, and many services are also flexible and self-healing. Containerization has platform-independent and standardized features that can seamlessly switch between cloud platforms. Because of the high utilization of resources, it is more suitable for deploying microservices, and it also has the characteristics of easy scalability.
Based on the four perspectives of architecture, infrastructure, engineering practices, and organizational structure, the concept of cloud native is proposed, which is mainly to make services or organizations more suitable for running on the cloud. At the architectural level, microservices are the standard architecture recommended by the cloud native and the practice of 12factors applications. The infrastructure level mainly involves cloudification and containerization. At the engineering practice level, the DevOps concept is used to make the delivery process smoother and the organizational structure The above is decentralization, letting the team be autonomous.
Neither cloudization nor microservices can be accomplished simply, and there are still many challenges. The first is the challenge of cloudification. There are two main points. One is how to transform the legacy system to be more suitable for the cloud, and the other is how to use the existing cloud services more effectively.
The challenges of microservices are as follows. One is the higher cost of rebuilding legacy systems. From the perspective of microservice splitting, the higher the complexity of the business, the more difficult it will be to split. The second is the problem of microservice development frameworks. The current microservice frameworks are only a few of Java's Spring Cloud and GO's ServiceComb. On the other hand, although these frameworks can provide fusing and service governance capabilities, they have improved The team’s learning costs and upgrade and maintenance costs. The third is the imperfect governance of microservices. The fourth is about the monitoring and operation of microservices, such as logs and calls.
Cloud design pattern
The cloud design pattern was launched by the Microsoft Azure Architecture Center, which provides 32 cloud design patterns and is a repeatable cloud solution. We believe that the design pattern solves the repetitiveness of software, and the cloud design pattern solves the repetitiveness of cloudification.
Classification and content of cloud design patterns
Azure abstracts different cloud design patterns from the perspectives of availability, data management, design implementation, messaging, management and monitoring, performance and scalability, elasticity, and security. The description of each pattern follows the pattern description, background, and problems. , Solutions, problems and precautions, when to use, cases, related patterns and guidelines. Some of these design patterns will be introduced in detail below.
Availability mode: health endpoint monitoring mode
The service monitoring method we generally use is not suitable for micro-service scenarios. On the one hand, it is time lag, and on the other hand, it is not accurate enough. Assuming such a scenario, service A depends on service B and a certain database, and at a certain moment we receive a warning about the slow response of service A. At this time, we may not be able to determine whether the problem lies in service B or the database. We can only check The log system can detect the problem.
针对上面的问题健康端点监控系统给出了解决方案，它在应用程序内部实现了检查的功能，外部工具可以定期通过暴露出去的端点访问，以帮助验证应用程序和服务是否正常运行。
数据管理模式：静态内容托管模式
静态内容托管模式是将静态内容部署到云存储服务，然后直接返回给浏览器（前后端分离就是使用这样的模式），当要进行请求的时候，使用CDN来提升性能。这样带来的好处就是完全不用维护，因为这是一个托管服务，也不需要使用工具做监控，同时这样对基础设施的开销也更低。
设计和实现——绞杀者模式
绞杀者模式是服务解耦常用的一种模式，简单来说就是用新的应用程序和服务逐步替换特定的功能。 创建一个外层来拦截请求前往后端旧版系统。 外层可将这些请求路由到旧版应用程序或新服务。 现有功能可逐步迁移到新系统，使用者可继续使用相同的接口，他们并不知道迁移已发生。
设计和实现——网关聚合模式
前后端分离中前端会请求很多的API数据，这不仅造成了网络和性能的损耗，同时也会给服务器带压力。使用网关能够减少客户端与服务之间的通信频率。 网关会接收客户端请求，将请求分派到不同的后端系统，然后聚合结果并将其返回给请求客户端。
设计和实现——网关路由模式
网关路由模式类似Nginx反向代理，在一组应用程序、服务或部署前放置网关。 使用应用层 7 路由将请求路由到相应实例。使用此模式，客户端应用程序只需了解单个终结点并与之通信。 如果服务进行合并或分解，客户端不一定需要更新。 它可以继续向网关发出请求，只有路由会更改。
Service Mesh
Service Mesh是用来处理服务间通信的基础设施层，在服务拓扑间实现请求可靠传递，通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。Service Mesh的网络代理能够实现很多功能，比如服务发现、负载均衡等，对比微服务框架它让开发者能够更专注于业务开发。而之所以被叫做服务网格，是由于sidecar（单个服务调用）连接起来类似网格。
Istio
Istio是Service Mesh的一个实现，它分为控制面和数据面。数据面就是代理，通过sidecar挎斗模式接入服务，由于和服务本身没有关系，所以可以使用HTTP2、gRPC不同协议等。控制面分为Pilot、Mixer、Istio-Auth三个部分，Pilot包含服务发现、路由、负载均衡等功能，Mixer可以做代理的访问控制、遥测、监控、指标收集、限流等，Istio-Auth负责身份验证、秘钥管理、审计等。
Service Mesh带来的好处显而易见，首先是能够0侵入接入遗留系统或者无微服务框架系统，其次应用层只需要关注业务逻辑，还解决了微服务监控、运维、治理等问题，最后Service Mesh本身的升级和运维是独立的。
目前Service Mesh还是一个比较新的概念，所以还没有能够完全在生产环境中使用。它在数据面工具还算比较多，有Linkerd、Nginx、Envoy、Mesher、Conduit，控制面则寥寥无几，现阶段只有有Istio和CSE。这些工具由于都是容器化的，所以大部分都是运行在k8s上。
注：本话题分享时，Istio还处于比较早期的版本，在0.6以后，我们尝试使用Istio，在生产环境上部署流量较少，不那么重要的服务。从实际的使用过程来看，它在如下方面带来的极大的好处：
1）开发可以专注业务代码开发，服务治理的任务交给Istio来完成。
2）可以根据服务特性，采用合适的语言开发，不用担心服务注册发现客户端引入的问题。
3）使用很小的成本就可以实现0宕机时间的自动化部署以及灰度发布。
在目前的使用中，我们使用Istio遇到的问题主要是Kubenetes的维护上，以及Istio本身还不够成熟，遇到的bug通常只能通过升级、重启去解决，团队缺乏Istio的经验。当然这些随着Istio本身的成熟以及团队成员进一步的总结学习，是可以解决的。