Alimei’s Guide:Architect is a team leader who can not only control the whole but also understand the local bottlenecks and provide solutions according to specific business scenarios. Behind the seemingly perfect “personality model”, it is a hard exploration. Today, nine Mo, a technical expert from Alibaba, systematically summarizes many years of experience to help more architects walk more “smoothly” and more “elegantly” on the road of advancement.
The architect is not a person, he needs to establish an efficient and excellent system, lead the team to seize the city and land, and complete the project within the specified time.
Architects need to be able to identify, define and confirm requirements, decompose systems into an overall architecture, correctly select technology, formulate technical specifications and effectively promote implementation.
According to the definition of togaf, the responsibility of an architect is to understand and pay attention to some key details and interfaces that are actually important but not overloaded. The role of an architect is to understand and analyze requirements, create useful models, confirm, refine and expand models, and manage architecture.
From the perspective of the industry, the understanding of architects can be roughly divided into:
- Enterprise Architect: focus on the design of the overall IT architecture of the enterprise.
- It Architect – software product Architect: focus on the development of software products.
- It Architect – Application Architect: focus on customizing it solutions in combination with enterprise needs; most of the work to be delivered includes the overall architecture, application architecture, data architecture, and even deployment architecture.
- It Architect – Technical Architect: focus on infrastructure, some software and hardware system, even cloud platform, submit: product proposal, product selection, deployment architecture, network scheme, even data center construction scheme, etc.
There is no special architect in the job title in Alibaba. The architect exists in more roles. Now there are two visible Titles: the chief architect and the solution architect. The solution architect has been set in most Bu at present, especially in Alibaba cloud and e-commerce system.
How to work
- Understand and mine customer pain points, project definition, existing environmental management;
- Sort out high-level requirements and non functional requirements;
- What assets do customers have? What solutions do star ring (Alibaba e-commerce operating system) / Alibaba cloud have;
- Communication, proposal, multiple iterations, delivery of the overall architecture;
- Architectural decisions.
1. From the customer view:
- Strengthen the customer’s high-level confidence: use the architecture and solution capabilities to help customers choose the star ring / alicloud platform.
- Solve middle-level problems of customers: help customers solve business problems and obtain business value by using star ring / alicloud platform services + application architecture design / solution capabilities.
- Lead customers’ IT staff and Alibaba ecological students: technology leading, method leading and product leading.
2. From the project view:
- Docking management department: report technical proposal, progress; technical communication.
- Interface with customer PM, project pm: assist in project planning, personnel management, etc. Responsible for the guidance of all technical deliverables.
- Connect business departments and demand personnel: understand and tap pain points, help sort out advanced business requirements, and guide demand process.
- Docking development: product support, technical guidance, architecture guidance.
- Docking test: cooperate with test plan and process development. Cooperate with performance test or non functional test.
- Docking operation and maintenance: product support, operation and maintenance support.
- Docking configuration & Environment: product support.
- Others: Alibaba technology resources aggregation.
3. From the inside of Alibaba:
- Sales plan support;
- Market promotion and implementation;
- Customer demand facade;
- Solution precipitation.
The architect’s responsibilities are clear, so what architectural thinking can guide the architectural design? Look at the architectural thinking below.
Build architecture from top to bottom
The main points are as follows:
1. Define the problem first, and the most important thing in defining the problem is to define the customer’s problem. Define the problem, especially identify the key problem. The key problem is to have a sense of body to the customer, to be able to solve the customer pain points, to be measured and identified through a certain degree of data, and to give priority to the solution of the key problem.
2. The time dimension must be added to the problem definition to distinguish the means / schemes from the problem definition.
3. In the definition of a problem, it is necessary to think about the problem in a higher level and then in a higher dimension, so as to really grasp the essence of the problem, clarify and excavate the needs, and make good use of the first principle thinking to analyze and think about the problem.
4. Problem solving principle: solve the customer’s problems (mission) first, then solve their own problems (vision); it is important to remember that it is not to emphasize how we are, but what problems we can specifically solve for customers, and then what we become, so as to better serve customers.
5. Make good use of various methods to analyze customer problems and convert them into the capabilities that our products or platforms need to provide, such as what business capabilities WMS can provide.
6. Sort out our existing processes and capability models, find out the areas that need to be improved, and really clarify the parts that need to be improved.
7. Define indicators, disassemble them, and then build mathematical models.
8. Transform the abstract capability demands into technical challenges. This step is equivalent to finding the target for the technicians, who can design the scheme. It needs to combine the bottom-up architecture derivation.
9. Innovation can be business innovation, product innovation, technology innovation, operation innovation, thinking of upgrading layer and dimension, using philosophy thinking such as first principle thinking, biology (evolution = variation + selection + isolation, entropy increase law, fractal and emergence) thinking, etc. can help us find different innovation in business, product and technology Probably. It can be said that philosophy thinking is the soul thinking of architects.
Deduce application architecture from bottom to top
First, according to the business process, the system time sequence diagram is decomposed, and then the modules are summarized according to the time sequence diagram, so as to get the modules with larger granularity, and the whole system architecture is constructed by the combination / aggregation of modules.
Basically, the derivation of application logic architecture has four sub paths, which are:
- Business concept architecture: business concept architecture comes from business concept model and business process;
- System model: from business concept model;
- System process: from business process;
- Non functional system support: it comes from the needs of performance, stability and cost.
Efficiency, stability and performance are the three main factors that most affect the implementation of logical architecture into physical architecture. Therefore, from logical architecture to physical architecture, it is necessary to make clear quantitative requirements for efficiency, stability and performance.
From bottom to top, it depends on deduction and induction.
If the product plan is clear, programmers need to understand the business requirements and derive the architecture according to the product plan. At this time, the bottom-up method is generally used, and domain modeling is the bottom-up analysis method.
For the bottom-up analysis method, if you refine the following keywords, you will get the following two keywords:
1. deduction: deduction is logic deduction. The lower the level is, the more deduction is needed:
- From use case to business model, it belongs to deduction;
- From business model to system model, it also belongs to deduction;
- According to the current problems, it is deduced that some stability measures should be implemented, which is also deductive.
2. induction: the induction here is based on a certain dimension of things. The higher the level is, the more induction is needed:
- Problem space module division belongs to induction;
- Part of the logic architecture is also induction;
- According to a pile of stability problems, it is concluded that the corresponding operations need to be done before, during and after the event, that is, according to the time dimension.
Domain Driven Design Architecture
Most of the traditional architectures are based on domain model analysis architecture. For typical domain implementation model design, please refer to DDD (Domain Driven Design). For details, please refer to the book implementation Domain Driven Design. In addition, UML and pattern application are better in domain modeling practice. The former is more theoretical understanding, while the latter is easy to implement.
Domain division design steps:
1. Analyze the user demand scenario and identify the full-scale use case of the business;
2. Analyze the robust graph of the model and identify all entity objects in the business scenario. Robust graph is a method (robustness analysis) used in the process of requirement design, through which designers can understand the requirements more clearly and comprehensively. It is usually used for software architecture analysis after requirement analysis and before requirement design. It mainly focuses on design analysis of functional requirements. The requirement specification is its input information, and the design model is its output information. It is the first step in the transition from functional requirements to design solutions, focusing on identifying the relationship between the high-level responsibility modules and planning modules that make up the software system. The robust graph contains three kinds of graphs: boundary, control and entity. The three graphs are as follows:
3、 Domain division, which classifies all identified entity objects;
4. Evaluate the rationality of domain division and optimize it.
Data driven design architecture
With the development of IOT, big data and artificial intelligence, domain driven architecture can not meet the needs or achieve the expected results. In the era of big data, in the big data application scenario, we need to change our thinking, from domain analysis to business architecture, application architecture, data architecture and technical architecture based on the results of big data statistical analysis. The architect is required to have the foundation of mathematical statistics analysis and Bi ability, and structure the system with data thinking. Typical systems are like Alibaba’s data analysis platform, cloud collection room and rookie’s data analysis platform, FBI.
The above-mentioned four kinds of thinking are often used in the architecture design. It is necessary to choose the thinking mode according to the needs of the business or system.
With the guidance of architecture thinking, is there a general / standardized architecture framework to better implement architecture design? See the common architecture framework. The following architecture framework actually contains some important architectural thinking.
Common architecture framework
Togaf is the abbreviation of the open group architecture framework, which is developed by the open group. The open group is a non-profit technology industry alliance, which constantly updates and reaffirms togaf.
Togaf emphasizes business objectives as the driving force of architecture, and provides a repository of best practices, including togaf architecture development method (ADM), togaf architecture content framework, togaf reference model, architecture development method (ADM) guidance and technology, enterprise continuum and togaf capability framework.
ADM is an iterative sequence of steps to develop an enterprise wide architecture approach.
Architecture content framework
ADM guidance and technology
1. Architecture iteration phase:
2. Using ADM at different levels:
3. Classification of stakeholders:
Architecture guidance and support solution: basic general system industry organization specific
(for more information, please refer to togaf Standard Version 9.1 or
The first most influential framework methodology is the Zachman framework, which was first proposed by John Zachman in 1987.
The Zachman framework model is divided into two dimensions: the horizontal dimension is organized by 6W (what, how, where, who, when and why), and the vertical dimension reflects the IT architecture level, from top-down, which are scope model, enterprise model, system model, technology model, detailed model and function model. Combining 6W horizontally, Zachman framework respectively answers six questions: what, how, where, who, when and why by data, function, network, personnel, time and motivation.
Itsa was born in HP in 1986, the world’s first enterprise architecture framework (IT strategy and Architecture). The modeling principle is “everything you need, and nothing you don’t”. Only put what you want.
DoDAF is the architecture framework of the U.S. Department of defense. It is an organizational mechanism to control “EA development, maintenance and decision-making generation”. It is the overall structure to unify “team resources, description and control EA activities”.
DoDAF covers all business areas of DoD, defines standard methods for representing, describing and integrating many architectures within the scope of DoD, ensures that architecture descriptions can be compared and evaluated, provides a common architecture foundation for understanding, comparing, integrating and interoperating FOS (system family) and SOS (system), provides rules and guidelines for developing and expressing architecture descriptions, but does not guide how to implement them.
The core of DoDAF is 8 viewpoints and 52 models.
1. Panoramic view AV
A top-level overview of the architectural description associated with all viewpoints. Provides general information about the architecture description, such as the scope and context of the architecture description. The scope includes the areas of expertise and timeframes described by the architecture. The context consists of interrelated conditions that form the context of the architectural description, including doctrine, tactics, technology, and procedures, descriptions of related objectives and concepts, concepts of operations (CONOPS), scenarios, and environmental conditions.
2. Capability viewpoint CV
The capability perspective (CV) focuses on the organizational goals related to the overall vision, which refers to the ability to conduct specific action processes or achieve desired results under specific standards and conditions, and they use a variety of means and ways to complete a set of tasks.
The CV provides a strategic context and corresponding high-level scope for the capabilities described in the architecture description, which is more comprehensive than the scenario based scope defined in the operational concept map.
These models are high-level and describe capabilities in terms that are easy for decision makers to understand in order to communicate the strategic vision of capability evolution.
3. Operational viewpoint ov
The operational point of view (OV) focuses on the organizations, tasks, or actions that accomplish the DOD mission and the information that must be exchanged between them. Describe the type, frequency and nature of information exchange, and what tasks and activities information exchange supports.
4. Service view SVCV
The service point of view (SVCV) focuses on the systems, services and interwoven functions that support operations. DOD processes include operational, operational, intelligence, and infrastructure functions. SVCV functions and service resources and elements can be linked to architecture data in 0V. These system functions and service resources support operations and facilitate information exchange.
5. System viewpoint SV
The system viewpoint (SV) focuses on information that supports automated systems, cross links, and other system functions in operations. With the emphasis on service-oriented environment and cloud computing, there may not be a system perspective in future versions of DoDAF.
6. Data point of view div
Data and information viewpoint (DIV), or data and information viewpoint for short, reflects the business information requirements and structured business process rules in the description of architecture.
Describe the information related to information exchange in architecture description, such as attributes, characteristics and interrelations.
When necessary, the data used in this viewpoint model needs to be considered by multiple architecture teams.
7. Standard viewpoint stdv
Standard viewpoint (stdv) is the minimum set of rules used to control the arrangement, interaction and interdependence of all components or elements of the system. Its purpose is to ensure that the system can meet a specific set of operational requirements.
The standard viewpoint provides the implementation guide of the technical system, establishes the general building blocks and develops the product line based on the engineering specifications.
It includes a series of technical standards, implementation practices, standard options, rules and specifications. These standards can form the files (Profiles) of control system and system / service elements in specific architecture description.
8. Project viewpoint PV
The project viewpoint (PV) focuses on how the project is organized into an orderly combination of programs.
Describe the relationships between multiple programs, each responsible for delivering a specific system or capability.
Togaf, Zachman, itsa and DoDAF are very good architecture frameworks, especially the first two are widely used. Togaf also has special architecture certification. When we master these frameworks, do we need some architectural principles to guide more specific design? See below.
The design principle is the guiding ideology of architecture design. It guides us how to organize data and functions into classes, and how to link classes into components and programs. On the contrary, the main work of architecture is to decompose software into components. The design principles guide us how to decompose, the granularity of disassembly, the direction of dependence between components, the way of component decoupling, etc.
There are many design principles. The main principle of our architecture design is OCP (open close principle). At the level of class and code, there are SRP (single responsibility principle), LSP (Richter replacement principle), ISP (interface isolation principle), dip (dependency inversion principle); at the level of component, there are Rep (reuse, release equivalence principle), CCP (Common Closure Principle), CRP (Common Closure Principle) The three principles of dealing with component dependency are: no dependency ring principle, stable dependency principle and stable abstraction principle.
1. OCP (opening and closing principle): well designed software should be easy to extend and resist modification. This is our leading principle for architecture design. Other principles serve this principle.
2. SRP (single responsibility principle)Any software module should have and only have one reason for being modified. “The reason for being modified” refers to the user or owner of the system. The translation is that any module is only responsible for the value of one user. This principle guides us how to split components.
For example, CTO and coo need to count the working hours of employees. At present, they may require the same statistical method. We reuse a set of codes. Coo said that the working hours of weekends should be multiplied by two. After the codes are modified according to this requirement, CTO may come to abuse. Of course, this is a very simple example. In the actual project, there are many codes serving multiple value subjects, which brings great exploration cost and modification risk. In addition, when a code has multiple owners, there will be code merge conflict.
3. LSP (Richter’s replacement principle): when different implementations of the same interface replace each other, the behavior of the system should remain the same. This principle guides the interface and its implementation.
You must be very confused. When the same interface is implemented, their behavior must be the same, not necessarily. Suppose that the system behavior of rectangle is: area = width * height, let the square realize the interface of rectangle. When setw and Seth are called, the square does the same thing, and sets its side length. At this time, the unit test on the lower side can pass with rectangle, not with square. The same interface can be realized, but the system behavior has changed. This is a classic case of violating LSP.
4. ISP (interface isolation principle): does not depend on any unneeded methods, classes, or components. This principle guides our interface design. When we rely on an interface but only use some of its methods, we already rely on unnecessary methods or classes. When these methods or classes are changed, it will cause recompilation of our classes or redeployment of our components, which are unnecessary. So we’d better define a small interface and separate the methods used.
5. Dip (dependency reversal principle): refers to a specific form of decoupling (the traditional dependency is created at the high level, while the specific policy settings are applied to the low-level modules), which makes the high-level modules independent of the implementation details of the low-level modules, and the dependency is reversed (reversed), so that the low-level modules depend on the requirements abstraction of the high-level modules.
The direction of dependency across the build boundary is always the opposite of the direction of control flow. This principle guides us in the direction of designing dependencies among components.
The dependency inversion principle is a very operable principle. When you want to modify the dependency direction between components, abstract the classes that need to communicate between components as interfaces. Where the interface is on the boundary, the dependency points to which side.
6. Rep (reuse and release equivalent principle): the minimum granularity of software reuse shall be equal to the minimum granularity of software release. To put it bluntly, if we want to reuse a piece of code, we will extract it into components. This principle guides the granularity of component splitting.
7. CCP (Common Closure Principle): classes modified for the same purpose at the same time should be placed in the same component. CCP principle is the description of SRP principle at component level. This principle guides the granularity of our component splitting.
For most applications, maintainability is more important than reusability. Code modification caused by the same reason is better in the same component. If it is scattered in multiple components, the cost of development, submission and deployment will increase.
8. CRP (principle of common reuse): don’t force a component to depend on something it doesn’t need. CRP principle is the description of ISP principle at component level. This principle guides the granularity of our component splitting.
I believe you must have this experience. Component A is integrated, but component a depends on component B and C. Even if you can’t use components B and C at all, you have to integrate them. This is because you only use part of the capabilities of component A, and the extra capabilities in component a bring extra dependency. If you follow the principle of common reuse, you need to split a and keep only the parts you want to use.
There is a competitive relationship among the three principles of Rep, CCP and CRP. Rep and CCP are cohesive principles, which will make components larger, while CRP principle is exclusion principle, which will make components smaller. If you follow rep or CRP and ignore CRP, you will rely on too many unused components and classes, and the changes of these components or classes will lead to too many unnecessary releases of your own components; if you follow rep or CRP and ignore CCP, because the components are split too carefully, a requirement change can change n components, and the cost is huge.
In addition to the above design principles, there are also some important guiding principles as follows:
1.N+1 design: each component in the system shall be free from single point of failure;
2. Rollback design: ensure that the system can be forward compatible, and there should be a way to roll back the version when upgrading the system;
3. Disable design: it shall provide the configuration to control whether the specific functions are available, and be able to quickly get offline in case of system failure;
4. Monitoring design: in the design stage, monitoring means should be considered to facilitate effective troubleshooting, such as the introduction of traceid and business ID to facilitate troubleshooting and monitoring;
5. Design of multi live data center: if the system needs high availability, multiple activities in multiple data centers shall be considered, and the system shall still be available when at least one computer room is powered off;
6. Adopt mature technologyThere are many hidden bugs in the newly developed or open source technologies. If there are problems, it may be a disaster if there is no good commercial support;
7. Resource isolation design: avoid single business occupying all resources;
8. Architecture level expansion designOnly when the system can be expanded horizontally can the bottleneck be avoided effectively;
9. Principle of non core purchase: if the non core functions need to occupy a large amount of R & D resources to be solved, consider purchasing mature products;
10. Use of commercial hardwareCommercial hardware can effectively reduce the probability of hardware failure;
11. Fast iteration: the system should develop small function modules quickly, go online for verification as soon as possible, find problems as soon as possible and greatly reduce the risk of system delivery;
12. Stateless design: the service interface should be stateless. The access of the current interface does not depend on the last access state of the interface.
Architects know their responsibilities, have good architectural thinking, master general architecture framework and methodology, and use architecture principles for architecture design. Different business and system requirements are different. Is there a system architecture design for different scenarios? The following describes the evolution of distributed architecture, cellular architecture, service-oriented SOA architecture, micro service architecture, and serverless architecture, so as to facilitate our reference in practical application.
Evolution of distributed architecture
Initial stage architecture
Features: application, database, file and other resources are all on one server.
Separation of application service, data service and file service
Note: the good times are not long. It is found that with the increase of system access again, the pressure of web server machine will rise to a higher level in the peak period. At this time, it is considered to add a web server.
Features: applications, databases, and files are deployed on separate resources.
Use cache to improve performance
Note: the characteristics of system access follow the law of 28, that is, 80% of business access is concentrated on 20% of data. Cache is divided into local cache and remote distributed cache. Local cache has faster access speed but limited cache data. At the same time, it competes with applications for memory.
Features: a small part of the data with centralized access in the database is stored in the cache server, reducing the number of database accesses and reducing the pressure of database access.
Using the application server cluster
Note: after finishing the work of database and table, the pressure on the database has been reduced to a low level, and we start to live a happy life of watching the traffic surge every day. Suddenly one day, I found that the access of the system began to slow down again. At this time, I first checked the database and found that the pressure was all normal. Then I checked the webserver and found that Apache blocked many requests, and the application server was also relatively fast for each request. It seems that the number of requests was too high, which led to the need to wait in line and the response speed became slow.
Features: multiple servers provide services to the outside through load balancing at the same time, solving the problem of single server’s processing capacity and upper limit of storage space.
Description: cluster is a common method to solve the problem of high concurrency and massive data. By adding resources to the cluster and improving the concurrent processing ability of the system, the load pressure of the server is no longer the bottleneck of the whole system.
Database read write separation
Note: after enjoying the happiness of high-speed growth of system visits for a period of time, I found that the system began to slow down again. What’s the situation this time? After searching, I found that the resource competition of some database connections of database write and update operations is very fierce, leading to the slow down of the system.
Feature: the database is introduced into the active / standby deployment.
Description: the database is divided into read database and write database. Through the introduction of master-slave database service, the read and write operations are processed in different database services. There can be multiple read databases. The write database data is synchronized to the read database through the synchronization mechanism. For the scenario where the latest write data needs to be queried, the latest data can be obtained by writing one more copy in the cache.
Reverse proxy and CDN acceleration
Features: CDN and reverse agent are used to speed up system access.
Description: in order to cope with the complex network environment and the access of users in different regions, CDN and reverse agent are used to speed up the access of users and reduce the load pressure of back-end servers. The basic principle of CDN and reverse proxy is caching.
Distributed file system and distributed database
Note: with the continuous operation of the system, the amount of data began to increase substantially. At this time, it was found that the query would still be slow after the sub database, so the sub table work was started according to the idea of sub database
Features: the database adopts distributed database, and the file system adopts distributed file system.
Description: any powerful single server can not meet the continuous growth of business needs of large-scale systems. With the development of business, database read-write separation will ultimately not meet the needs. It needs to use distributed database and distributed file system to support.
Distributed database is the final method of system database splitting, which can only be used when the scale of single table data is very large. The more common method of database splitting is business sub database, which deploys different business databases on different physical servers.
Using NoSQL and search engines
Features: the system introduces NoSQL database and search engine.
Description: as the business becomes more and more complex, the demand for data storage and retrieval becomes more and more complex. The system needs to use some non relational databases such as NoSQL and sub database query technologies such as search engine.
The application server accesses all kinds of data through the unified data access module, which reduces the trouble of application program in managing many data sources.
Features: the system is divided and transformed according to the business, and the application server is deployed according to the business differentiation.
Description: in order to deal with increasingly complex business scenarios, the whole system business is usually divided into different product lines by means of divide and conquer. The relationship between applications can be established through hyperlinks, and the data can be distributed through message queues. Of course, more of the same data storage system is accessed to form an associated complete system.
Vertical splitting: a large application is divided into several small applications. If the new business is relatively independent, it is relatively simple to directly design and deploy it as an independent web application system. By combing the business, fewer related businesses can be separated.
Horizontal split: split the reused services and deploy them as distributed services independently. New businesses only need to call these distributed services. Horizontal split needs to identify reusable businesses, design service interfaces and standardize service dependency.
Features: the common application modules are extracted and deployed on the distributed server to provide server calls.
Description: as the business becomes smaller and smaller, the overall complexity of the application system increases exponentially. As all applications need to connect with all database systems, the database connection resources are insufficient and services are refused.
Problems and challenges of distributed services:
(1) When more and more services are provided, the configuration management of service URL becomes very difficult, and the single point pressure of F5 hardware load balancer is also increasing.
(2) When further development, the interdependency between services becomes complex, and it is even unclear which application needs to be started before which one, the architect can not completely describe the architectural relationship of the application.
(3) With the increasing number of service calls, the problem of service capacity is exposed. How many machines does this service need? When should I add the machine?
(4) There are more services, and communication costs are also rising. Who should I look for when I fail to transfer a service? What are the service parameters?
(5) A service has multiple business consumers, how to ensure the quality of service?
(6) With the continuous upgrading of services, there are always some unexpected things happen, such as memory overflow caused by cache write error, failure is inevitable, every time the core services hang up, affecting a large area, people panic, how to control the impact of failure? Can the service be degraded? Or resource degradation?
To solve these problems, the following cellular architecture, microservice architecture and service architecture can be solved to a certain extent. In addition, for business systems, the above problems can only be solved by separating business from business, management domain from operation domain, and business from platform.
1. What is unitization: unitization architecture is developed from the field of parallel computing. In the field of distributed service design, a cell is a self-contained installation that satisfies all business operations of a partition. A shard is a subset of the whole data set. If you use the suffix to divide users, the users with the same suffix can be regarded as a partition. Unitization is the process of transforming a service design to conform to its unit characteristics.
2. The necessity of unitization: with the continuous upgrading of hardware, the computer hardware capacity has become stronger and stronger, the CPU is faster and faster, the memory is larger and larger, and the network is wider and wider. This gives us the opportunity to scale vertically on a single machine. Especially when you encounter a business with predictable performance requirements and capacity growth, modularization provides us with another opportunity to effectively reduce the use of resources and provide higher performance services.
Higher performance and lower cost are our main goal. After the unit transformation, we can use fewer (about one-half) machines to achieve higher (nearly 100 times) performance than before. Most of the performance improvement is due to the localization of services, and the integrated deployment of services further reduces the use of resources. In addition to performance benefits, there are many benefits, such as better isolation, including request isolation and resource isolation, such as more friendly upgrades, products can be released in gray scale, etc. After the unit transformation, how to deal with the peak and how to expand the capacity are discussed.
3. How to achieve modularity: first, look at the traditional service architecture in the figure below. Services are layered. Each layer uses different partition algorithms. Each layer has different number of nodes. The upper node randomly selects the lower node.
In the cellular architecture, although services are divided hierarchically, each unit is a whole. In terms of hierarchy, all layers use the same partition algorithm, each layer has the same number of nodes, and the upper node will also access the specified lower node.
SOA (Service-Oriented Architecture) is a component model, which links different functional units of applications (called services) through well-defined interfaces and contracts between these services. The interface is defined in a neutral way, which should be independent of the hardware platform, operating system and programming language to implement the service. This enables services built into a variety of systems to interact in a unified and common way. Service oriented architecture can deploy, combine and use loosely coupled coarse-grained application components through the network according to the requirements. The service layer is the foundation of SOA, which can be directly called by applications, so as to effectively control the human dependency of interaction with software agents in the system.
The implementation of SOA has several distinct basic characteristics. The key goal of implementing SOA is to maximize enterprise IT assets. To achieve this goal, the following characteristics should be kept in mind during the implementation of SOA:
(1) Accessible from outside the enterprise
(2) Ready to use
(3) Coarse grained service interface classification
(4) Loose coupling
(5) Reusable services
(6) Service interface design management
(7) Standardized service interface
(8) Support various message modes
(9) Precisely defined service contracts
In order to implement SOA, an enterprise needs a service architecture. The following figure shows an example:
In the figure above, the service consumer can call the service by sending a message. These messages are transformed by a service bus and sent to the appropriate service implementation. This service architecture can provide a business rules engine, which allows business rules to be merged into one or more services. This architecture also provides a service management infrastructure to manage services, such as auditing, listing, logging and other functions. In addition, the architecture provides enterprises with flexible business processes, better handling of regulatory requirements, such as Sarbanes Oxley (SOx), and the ability to change a service without affecting other services.
Let’s first look at the traditional way of web development. It’s easier to understand what is microservice architecture through comparison. Corresponding to microservice, this approach is generally called monolithic.
All functions are packaged in a war package, basically without external dependency (except for containers). They are deployed in a Jee container (tomcat, JBoss, Weblogic), including do / Dao, service, UI and other logic.
- Simple development and centralized management;
- It will not be developed repeatedly;
- All functions are local, without distributed management and call consumption.
- Low efficiency: the development is changing the code in the same project, waiting for each other, and the conflict is constant;
- Difficult to maintain: code function is coupled together, new people don’t know how to start;
- Inflexible: it takes a long time to build, and any small modification needs to reconstruct the whole project, which is time-consuming;
- Poor stability: a small problem may cause the whole application to hang up;
- Insufficient scalability: unable to meet high and distributed business requirements.
Common system architecture follows three standards and business drivers:
- Improve agility: respond to business needs in time and promote enterprise development;
- Improve user experience: improve user experience and reduce user churn;
- Reduce cost: reduce the cost of adding products, customers or business solutions.
Design based on microservice architecture:
Objective: to effectively split the application and realize agile development and deployment.
An image expression of microservices:
- X axis: running instance after running multiple load balancers;
- Y axis: further decompose the application into microservices (sub databases);
- Z axis: when there is a large amount of data, partition the service (table).
Differences between SOA and microservices:
- SOA likes reuse, and microservices like rewriting;
- SOA likes horizontal service, micro service likes vertical service;
- SOA likes top-down, and microservices like bottom-up.
1, thinkingNo server is an architectural concept. Its core idea is to abstract the infrastructure providing service resources into various services, provide users with API interface to call on demand, and truly achieve scaling on demand and charging on use.
2, advantages: it eliminates the demand for traditional massive continuous online server components, reduces the complexity of development and operation and maintenance, reduces operating costs and shortens the delivery cycle of business system, enabling users to focus on the development of business logic with higher value density.
3, content: at present, the more recognized serverless architecture in the industry mainly includes two aspects: FAAS, a functional service platform providing computing resources, and baas, a back-end service providing managed cloud services.
Function as a service: it is an event driven function managed computing service. Through the function service, developers only need to write business function code and set running conditions, without configuring and managing infrastructure such as servers. Function code runs in stateless containers, triggered by events, is short-lived and volatile, and is completely managed by a third party. The infrastructure is completely transparent to application developers. The function runs in a flexible and highly reliable way, and charges according to the actual execution resources, without any cost.
Back end as a service: baas covers all the third-party services that the application may depend on, such as cloud database, authentication, object storage and other services. Developers can integrate all the back-end functions required through APIs and SDKs provided by baas service providers, without building back-end applications or managing infrastructure such as virtual machines or containers Ensure the normal operation of the application.
Three less feel good:
- Codeless corresponds to service development and implements source code hosting. You only need to pay attention to your code implementation and not where your code is, because you will not feel the existence of code base and code branch in the whole development process.
- Applicationless corresponds to service publishing. In the service-oriented framework, your service publishing doesn’t need to apply for applications or pay attention to where your applications are.
- Serverless corresponds to service operation and maintenance. With the serverless capability, you no longer need to pay attention to your machine resources. Servlerless will help you with the elastic expansion and contraction of machine resources.
After completing the above architecture design, the architect needs to cooperate with the stakeholders to get the results according to the project operation. Then how to ensure the satisfaction of the stakeholders in the project implementation, and how to ensure the successful results according to the architecture? Architecture management capability is a very important capability for architects.
Architecture win-win model
Architecture result management
Statement: some of the contents of this article refer to some internal and external articles of Ali, see the above reference materials for details; the focus of writing this article is to systematically summarize and understand the work of architects, so as to facilitate better interactive learning and growth, and some of the views are personal views.
Author: Jiu Mo
Read the original text
This article is from alitech, a partner of yunqi community. If you need to reprint it, please contact the original author.