1. Differences between SOA architecture and microservices Architecture First, SOA and microservices architecture are one level of things, while ESB and microservices gateway are one level of things, one talking about architectural style and approach, and one talking about implementation tools or components. 1. Service Oriented Architecture (SOA) : It is a design approach in which multiple services are interdependent to provide a series of functions. A service usually exists in a separate operating system process. Services are invoked over the network. 2. Microservice architecture: In fact, similar to SOA architecture, microservice is the sublimation of SOA. One of the key points of microservice architecture is that “business needs to be thoroughly componentalized and servitized”. These small applications interact and integrate with each other through services. Microservices Architecture = 80% SOA service architecture thought + 100% componentized architecture thought + 80% domain modeling thought 2.ESB and Microservices API gateway. 1.ESB (Enterprise Service Bus). Simply put, an ESB is a pipe connecting service nodes. In order to integrate services of different systems and protocols, THE ESB does message translation, interpretation and routing to make different services interconnect.
2.API Gateway: THE API gateway is a server and a unique entry to the system. From an object-oriented design perspective, it is similar to the appearance pattern. The API gateway encapsulates the internal architecture of the system and provides a custom API for each client. It may also have other responsibilities, such as authentication, monitoring, load balancing, caching, request sharding and management, and static response processing. The core point of the API gateway approach is that all clients and consumers access microservices through a unified gateway and handle all non-business functions at the gateway layer. Typically, gateways also provide REST/HTTP access apis. The server registers and manages services through API-GW.
3. The SOA architecture features: system integration: stand in the perspective of system, solve the communication problem between enterprise system, the originally scattered, no planning system between the reticular structure, combing into neat, a governance system between star structure, this step is often need to introduce some products, such as ESB, as well as the technical specifications, standard service management; This step is the core of the problem of service system of orderly 】 【 : stand in the Angle of the function, the business logic into abstract reusable and can be assembled services, through the service arrangement provides rapid regeneration, the business purpose: to transform the business functions inherent to the original for the general business services, achieve rapid reuse of business logic; The core problem of this step is the servitization of [reuse] business: from the perspective of enterprises, the functions of enterprises are abstracted into reusable and assemblable services; Transform the former functional enterprise architecture into a service-oriented enterprise architecture to further enhance the external service capabilities of enterprises; “The first two steps are from the technical level to solve the problem of system call, system function reuse”. The third step is to encapsulate a business unit into a service with a business driver. The core problem solved in this step is [efficiency]. 4. Characteristics of microservice architecture: 1. 2. Services and development teams are divided according to business capabilities. Developers are free to choose development technologies and provide API services. Decentralization Each microservice has its own private database to persist service data. Each microservice can only access its own database, but cannot access the databases of other services. In some business scenarios, multiple databases need to be updated in a transaction. In this case, there is no direct access to other microservices’ databases, but rather through operations on microservices. Data decentralization further reduces the degree of coupling between microservices, and different services can use different database technologies (SQL, NoSQL, etc.). In complex business scenarios, if multiple microservices are involved, they are typically handled on the client side or in the middle tier (gateway). 4. Infrastructure automation (DevOPS, automated deployment) Java EE deployment architecture, the WARs are packaged by the presentation layer, the business layer is divided into JARs and finally deployed into a big package EAR, while the microservices open the black box, the application is broken down into a single service one by one, using Docker technology, Do not rely on any server and data model, and it is a whole stack application, can independently by automated deployment, each service operation in the process of their own, through lightweight communication mechanism, is often based on HTTP resource API, these services based on the business ability to build, can realize centralized management (because the service too much, You can’t DevOps without centralized management). 5. Main differences:
The subcontracting service interface, request service model and exception information are all placed in the API, which conforms to the principle of reuse and publish equivalence. The principle of common reuse is put into the API of Spring reference configuration. It can also be placed in the module’s package directory. Granularity Make the interface as coarse-grained as possible, with each service method representing an independent function rather than a step of a function. Otherwise, it will involve the distributed transaction service interface. It is recommended to divide the interface into business scenarios. It is not recommended to use too abstract general interface T T< generic >. The interface does not have clear semantics, bringing the later maintenance version. Each interface should define the version. Version (Maven-snapshot) It is recommended to use a two-digit version number, because the third digit indicates compatibility upgrades. Only the service version needs to be changed if the interface is not compatible with the upgrade. If the interface is not compatible with the upgrade, upgrade half or one provider to the new version first. And then upgrade all your purchases to the new version, On the provider side, configure the consumer side properties as much as possible, such as timeout, Retires, thread pool size, and LoadBalance to configure administrator information The owner configured on the application and the owner are recommended to configure more than two users. Because the owner can see the list of service providers in the monitoring center that configure the Dubbo cache file registry