Microsoft Application Architecture Guide (2nd Edition)
========== ========== ==========
Patterns & Practices
[translator] (2) Zhu ye, Gao Xiang and Wang Min
Electronic Industry Press
[edition] November 2010 1st Edition
[print time] the first printing in November 2010
[price] 69.00 yuan
========== ========== ==========
Developers and solution architects usually wander between “golden solution” and “instant solution”.
Architecture is the use of existing technologies and tools to create as much business value as possible. On the one hand, it focuses on the requirements and limitations of existing business, on the other hand, it focuses on the future to maximize value through scalability, flexibility and maintainability.
[chapter 01] [what is software architecture]
Software application architecture is a structured solution. On the one hand, this structured solution can meet all technical and operational requirements, on the other hand, it can meet the common quality attribute requirements, such as performance, security and manageability. It covers a series of decisions influenced by multiple factors, each of which has a significant impact on quality, performance, maintainability, and the overall success of the application.
The risks of a failed architecture include software instability, inability to support existing or future business requirements, or difficulty in deployment and management in a production environment.
Users, system (IT infrastructure) and business need to be considered when designing the system. For each aspect, you should list key application scenarios and identify important quality features (such as reliability or scalability) and satisfactory or unsatisfactory key points. If possible, establish criteria for measuring gains and losses in every aspect that needs to be considered.
Architecture focuses on the use and interaction of the main elements and components that make up an application. The design is mainly concerned with the selection of data structure and algorithm, as well as the implementation of component details.
Architects must consider the overall effect of design decisions, as well as inherent trade-offs, including trade-offs between numerous quality attributes and between user, system, and business requirements.
Remember that the architecture should:
1. Show the structure of the system, but hide the implementation details;
2. Be aware of all use cases and application scenarios;
3. Strive to take into account the needs of all participants;
4. Handling function and quality requirements;
Use patterns that have been proven in a large number of solutions to solve common problems.
Don’t over design the architecture, especially don’t make any assumptions about things that can’t be verified. We just need to make room for possible changes in the future during the design process.
[chapter 02] [key principles of software architecture]
Architecture focuses on organizing components to support specific functions.
When designing an application or system, the goal of a software architect is to minimize complexity by dividing the design into different concerns.
For each point, the component we designed focuses on this specific point, and should not mix the code of other concerns.
Separation of concerns – break your application down into different features with as little overlap as possible. The biggest advantage of this is that a feature or function can be optimized independently of other features or functions.
Make clear how to communicate between layers – if you allow layers in an application to communicate or rely on all other layers, it may make the solution more difficult to understand and manage, and you need to consider the dependencies between layers and the flow of data between layers.
Components or objects should not rely on the internal details of other components or objects — each component or object should only call a method of another component or object, and this method knows how to handle the request and forward it to the appropriate subcomponents or other components, which helps to create applications with higher maintainability and adaptability.
Ensure that crosscutting code is abstracted as much as possible from the application’s business logic – crosscutting code refers to code that has security, communications, or operational management such as logs and indicators.
Every application design must consider security and performance, but not every design needs to consider interoperability and scalability.
[chapter 03] [architecture mode and style]
Architectural style is sometimes referred to as architectural pattern. It is a set of principles coarse-grained pattern that provides abstract framework for a family of systems.
There are many advantages in understanding architecture style. The biggest advantage is that it provides a common expression and provides an opportunity for technology independent discussion. It allows us to have a high-level discussion on patterns and principles without involving specific details.
The architecture of software system is almost not limited to a single architecture style, but usually uses the combination of architecture styles to form a complete system.
The simplest client / server system includes server applications that can be directly accessed by multiple clients, also known as two-tier architecture style.
Design patterns such as dependency injection pattern or service locator can be used to manage dependencies between components and provide loose coupling and reuse.
Proper layering of your application can help you effectively separate concerns, thereby enhancing flexibility and maintainability.
Layered architecture style is often called inverted pyramid of reuse. Each layer aggregates the responsibilities and abstractions of the direct lower layer. For the strict hierarchical structure, the components in the layer can only interact with the components in the same layer or direct lower layer, while the loose hierarchical structure allows the components in the layer to interact with the components in the same layer and any subordinate layer.
Application layers may be on the same physical machine (same physical layer) or distributed on separate machines (n physical layer), and components in each layer communicate with components in other layers through well-defined interfaces.
Reusability – the lower layer does not depend on the upper layer, which makes the lower layer reusable in other application scenarios.
Loose coupling — communication between layers is based on abstraction and events, which provides loose coupling between layers.
Performance – scalability, fault tolerance, and performance can be improved by distributing the logical layer across multiple physical layers.
Message bus architecture usually uses message routing or publish / subscribe mode, and is usually implemented by message system such as message queue.
Complex processing logic – a group of small operations can be integrated to form a complex operation. Each small operation completes a specific task, and multiple small operations are combined into a multi-step operation.
N-tier or three-tier is a kind of architecture deployment style. It divides functions into different segments in a way similar to layered style, but each segment, as a physical layer, will be distributed on physically separated computers. It develops from a component-oriented approach, usually using a platform specific approach rather than a message based approach to communication.
The main features of N-tier application architecture are: separation of application functions, distributed deployment of service components and components, enhanced scalability, availability, manageability and full utilization of resources. Except for the upper and lower layers, each physical layer is completely independent of other layers. The n-layer only knows how to handle the request of the N + 1 layer, how to return the request to the N-1 layer (if any), and how to handle the result of the request. In general, the communication between layers is asynchronous in order to better support scalability.
N-tier architecture usually has at least three separate logical parts, each part is deployed on an independent physical server, and each part is responsible for specific functions. When using layered design, if more than one service or application uses the function of logical layer, it is deployed as physical layer.
The main advantages of N-tier / 3-tier architecture style are as follows:
1. Maintainability – because each layer is independent of other layers, the update or modification part will not affect the whole application;
2. Scalability – because the physical layer is deployed based on the logical layer, it becomes quite simple to scale out the application;
3. Flexibility: each layer is managed and expanded independently, which increases the flexibility;
4. Usability — the application program can use easily extensible components to form a modular system, which increases the usability;
By using a series of protocols and data formats to exchange information, SOA architecture style can package business processing into interoperable services. Clients and other services can access local services running on the same physical layer, and can also access remote services through the connected network.
[chapter 04] [Architecture and design method]
The architecture process should be iterative and incremental.
In the process of architecture and design, use case describes a group of interaction behaviors, which can be the interaction between the system and one or more factors (users or another system). Scenario describes the interaction between user and system in a broad sense, which does not go through the path of use case.
Architectural style is a set of principles. You can think of it as a coarse-grained pattern that provides an abstract framework for a family of systems. Each style defines a set of rules that specify the types of components that make up the system, the relationships between components, the constraints of assembly methods, and some assumptions used in assembly.
Architecture style can improve the hierarchical degree of the system, and improve the reusability of the design by providing solutions for the frequent problems.
Applications tend to use a combination of multiple styles.
When selecting the technologies you will use in your design, you need to consider which technologies can support the selected architecture style, application type, and key quality characteristics of the application.
It’s important to draw the architecture.
[chapter 05] [layered application guidelines]
Layer focuses on the logical division of components and functions, regardless of the physical location of components. Layers can be located in different physical layers or belong to the same physical layer.
We need to understand the difference between the logical layer and the physical layer. The logical layer describes the logical grouping of functions and components in an application, while the physical layer describes the physical distribution of functions and components to independent servers, computers, networks or remote locations.
It is common to put more than one logical layer on the same physical machine (one physical layer).
Layer helps to distinguish the different types of tasks carried out by components, so that our design can easily support component reuse.
Each logical layer contains many independent component types and is grouped into sub layers. Each sub layer performs a specific type of task.
Dividing the application into layers with different roles and functions not only helps to maximize the maintainability of the code, but also optimizes the working mode of the application by changing the deployment mode, and provides a clear description to show the technology or design decisions that must be implemented in each location.
From the most advanced and abstract point of view, any system in the logical architecture level can be seen as a group of collaborative components into a logical layer.
Presentation layer — this layer contains user oriented functions, which is responsible for managing the interaction between users and the system. It usually contains some components, which can be used to access the core business logic encapsulated in the business layer.
Business layer – this layer implements the core functions of the system and encapsulates the relevant business logic. It is usually composed of components that may expose service interfaces for use by other callers.
Data layer – this layer provides access to data hosted within the system boundary or exposed by other networked systems, which may be through services.
From a higher level, service-based solutions can be seen as composed of multiple services, each of which communicates with other services by delivering messages. Conceptually, services can be seen as components of the whole solution. However, internally, every service, like any other application, is composed of software components, which can be logically grouped into presentation layer, business layer and data layer.
If an application has to provide services for other applications, or to implement some features directly provided to the client, the usual way is to use the service layer to expose the business functions of the application.
When designing an application, the first thing is to focus on the highest level of abstraction, that is, the layering of functions, and then the common interface must be defined for each layer (depending on the type of application being designed). After defining the layer and interface, we must also decide the deployment mode of the application, and finally choose the communication protocol to be used for the interaction between the logical layer and the physical layer.
The use of layering can improve the maintainability of the application, and it is more convenient to scale out when the performance needs to be improved.
The first crucial step in determining the layering strategy is to determine the appropriate layering granularity for the application.
In order to maintain flexibility, it is always necessary to ensure that the interaction between layers is loosely coupled.
Layered approach will increase some complexity, and may increase the initial development time, but if implemented correctly, it will greatly improve the maintainability, scalability and flexibility of the application. There must be a trade-off between reusability, loose coupling, performance impact, and increased complexity. In general, the advantages of flexibility and maintainability provided by layered design far exceed the weak performance improvement brought by non layered tightly coupled design.
The most common approach in business applications is to separate presentation, service, business, and data access functions into separate layers. It also introduces some report infrastructure or application layer.
If you need to add a layer, please consider it carefully. If logical grouping of the associated components can not increase the maintainability, scalability or flexibility of the application, you should not add a layer.
Logical layers and components should be distributed across separate physical layers only when necessary.
It’s important to identify all the crosscutting concerns in your application and design separate components for each as much as possible. This way can help you get better reusability and maintainability.
When defining interfaces for layers, the primary goal is to achieve loose coupling between layers. That is to say, layers should not expose internal details for other layers to rely on. Instead, you should design interfaces for the layer to minimize dependencies by providing common interfaces that can hide the details of components in the layer. This kind of hiding is called abstraction, and there are many different ways to achieve it.
One layer does not depend on another layer, and all layers depend on the common interface.
[chapter 06] [guiding principles of performance layer]
The presentation layer contains components that implement and display user interfaces and manage user interactions. It contains some controls for user input and display and some components for organizing user interaction.
Caching is one of the best ways to improve application performance and UI response speed.
For long-running behavior, it is necessary to provide progress feedback for users. Consider allowing users to cancel long-running operations.
Unless the captured exception can be handled, do not use the custom exception casually, and do not use the exception to control the logical flow of the application.
Input validation should be handled by the presentation layer, while business rule validation should be handled by the business layer.
If your business layer and presentation layer are physically separated, the verification logic of business rules should also be implemented in the presentation layer to improve availability and response speed.
For ASP.NET Use viewstate carefully, because it may increase the amount of data in each round trip and reduce the performance of the application. Consider configuring the page to use a read-only session, or even not, if possible.
[chapter 07] [business level guidelines]
To maximize reuse, business logic components should not contain any behavior or application logic that can only be used for specific use cases or application scenarios.
When designing the business layer, the goal of software architects is to minimize complexity by dividing tasks into different concerns.
For each point, the components you design should focus on specific points, and should not contain code related to other concerns.
Independent business layers should be used as much as possible to improve the maintainability of applications.
If the business layer is used by both the presentation layer and external applications, you can choose to present the business layer through services.
Use abstraction principles to minimize coupling when creating interfaces for the business layer. Abstract techniques include using common object interfaces, common interface definitions, and abstracting base classes or messages.
Designing an effective authentication policy for the business layer is very important for the security and reliability of applications.
Designing an effective authorization policy for the business layer is very important for the security and reliability of applications.
For roles, we should consider reducing the granularity as much as possible to reduce the number of permission combinations required.
It is very important for application performance and response speed to design appropriate caching strategy for business layer.
Only necessary data is cached.
When designing components for the business layer, we should ensure that they are highly cohesive and have low coupling between layers. This can improve the scalability of the application.
Designing an effective exception management solution for the business layer is very important for the security and reliability of applications.
Designing effective logging, auditing and measurement solutions for the business layer is important for the security and reliability of applications.
Designing an effective verification solution for the business layer is important for the availability and reliability of applications.
[chapter 08] [data layer guidelines]
A policy must be determined to fill in the business entity or data structure from the data source and make it available to the business or presentation layer of the application.
Batch processing of database commands can improve the performance of the data layer. Each request to the database execution environment generates an overhead. The throughput can be improved and the total cost can be reduced by batching. Because databases can cache similar queries and reuse execution plans, batch processing of similar queries can improve performance.
If data is stored and obtained in the form of data stream, it can be considered as binary large object or blob.
Blob is generally used to store image data, but it can also be used to store binary representation of objects.
Choose the appropriate data format to provide interoperability with other applications, and use serialization to communicate across processes and across physical machines. Another reason why data format and serialization are particularly important is that it allows the business layer to store and retrieve application state.
As much as possible, the exception handling logic is centralized in the crosscutting components throughout the application.
In terms of the security and performance of stored procedure, parameterized query should be used in principle to avoid building dynamic SQL in stored procedure.
Keep in mind that using dynamic SQL in stored procedures can affect performance, security, and maintainability.
Transaction is the exchange of a group of ordered information and related behavior as atomic unit to meet the request and ensure the integrity of the database. Only when all the information and behaviors are completed and the relevant database changes take effect permanently, the transaction is considered completed. When an error is encountered, the transaction supports undo (rollback) database behavior, which helps to maintain the integrity of the data in the database.
By default, Microsoft SQL Server database executes each individual SQL statement as a separate transaction (the mode of automatic transaction submission).
Designing effective input and data validation policies is crucial for application security.
Datareader is very suitable for read-only forward operations, which can process every line quickly.
If you are accessing SQL Server 2008, you can use the file stream to access the BLOB data and have more storage flexibility.
Unless scalability and security should be considered, the data access layer and business logic layer can be placed in the same physical layer to improve the performance of the application.
[chapter 09] [service level guidelines]
If you want to provide application functions through services, it is very important to divide the service functions into independent service layers.
Service interfaces and data contracts (or message types) need to be defined and implemented in the service layer. It’s more important to remember that services should never expose internal processing details or used business entities in an application.
The service layer should provide the data format between the business layer entity and the data contract.
The service exposes the service interface to the message receiver. You can think of a service interface as a facade that exposes the business logic implemented within an application (typically in the business layer) to potential consumers.
Idempotent endpoints ensure that only one message is processed and duplicate messages are ignored.
The service interface represents the contract of service exposure. Contracts define the operations supported by your service and the parameters and data transfer objects associated with those operations.
The biggest mistake in the design of service interfaces is to treat services as components of fine-grained operations.
Representational state transfer (rest) and soap represent two different styles of service implementation. From a technical point of view, rest is an architectural pattern, which uses simple verbs to build and is very suitable for HTTP. Although the principles of rest architecture can be applied to non HTTP protocols, in practice, rest implementation is usually used in combination with HTTP. Soap is an XML based message protocol that can be used with any communication protocol, including http.
For simplicity, you can use ASP.NET Web Service (asmx), but there must be a server running Microsoft Internet Information Service (IIS).
If you need advanced features such as reliable sessions, transactions, activity tracking, message logging, performance counters, and support for multiple transport protocols, consider using WCF Services.
If you are sure to use WCF for the service:
1. If you want to interoperate with non WCF or non windows clients, you can consider using HTTP transmission based on soap specification;
2. If you want to support clients in LAN, you can consider using TCP protocol, binary message encoding, transmission security and windows authentication;
3. If WCF clients are located on the same machine, we can consider using named pipe protocol and binary message encoding;
[Chapter 10] [component guidelines]
Each layer of an application contains a series of components that implement the functions of that layer. These components should be highly cohesive and loosely coupled to simplify reuse and maintenance.
[Chapter 11] [design performance component]
The requirements of UI depend on the functions the application needs to support and the user’s expectations.
There is a very important factor in the choice of technology, which is the function required by UI.
According to the UI requirements, the UI type of the application can be determined. There are many different UI types, each with its advantages and disadvantages.
Rich client mobile applications can support offline or intermittent online application scenarios. Web or thin client mobile applications only support continuous application scenarios.
Rich Internet Applications (RIA) are usually web applications that have rich graphical user interfaces and run in browsers.
If the content of an application needs to be searched by a web search engine, a web application is suitable.
Console based applications provide a pure text user experience, and generally run in command line shells such as commands and windows or PowerShell. They are best suited for administrative or development tasks and are unlikely to be part of layered application design.
After determining the UI type for the UI component, you must also select the appropriate technology.
WPF applications provide interaction for developers / designers by separating UI and underlying control logic — allowing developers to focus on business logic while designers focus on perception.
AJAX is an important part of. Net Framework 3.5 and later ASP.NET The most important part of the game.
After choosing the implementation technology for UI, the next step is to design UI components and presentation logic components.
UI components are visual elements that display information to users and accept user input. In presentation separation mode, they generally refer to views.
Avoid creating custom controls unless you need special displays or special data sets. If you find that the UI requirements cannot be realized by using standard controls, you can consider purchasing a control development kit instead of writing your own custom controls. If you have to create custom controls, extend existing controls as much as possible instead of creating new ones. Consider extending the control through the behavior of additional control instead of inheriting from control, and consider implementing designer support for custom control to make it easier for developers to use.
The presentation logic component deals with the non visual aspects of the user interface. It includes verification, response to user behavior, communication between UI components and organization of user interaction.
If the UI needs complex processing or has to communicate with other layers, the presentation logic component can be used to decouple the processing of UI components.
The presentation model component represents the data in the business layer in a way that UI and presentation logic components in the presentation layer can use.
The performance model component should encapsulate the data, business logic and behavior in the business layer as much as possible.
Specific data binding technologies may require data sources to implement specific interfaces or events to fully support data binding, such as inotifypropertychanged in WPF or ibindinglist in Windows Forms.
[Chapter 12] [design business components]
Designing business components is a very important task. If you don’t design your business components correctly, the code will become difficult to maintain and expand.
The overall design of the application and the type of application determine which business components are used to process the request.
[Chapter 13] [design business entity]
Generally, XML is used only when the presentation layer needs or logic must cooperate with XML based data.
Note that using and manipulating XML consumes a lot of memory.
Microsoft. Net framework provides components that can reverse sequence XML data into objects and sequence objects into XML.
It is necessary to determine how to transport business entities across boundaries. In most cases, when transferring data across physical boundaries such as AppDomain, process, and service interface boundaries, you must serialize the data. Serialization should be considered even when transferring data across logical boundaries.
Data transfer object (dto) is a design pattern that can package multiple data structures into a single structure for cross boundary transmission.
Domain model uses entity, value object, aggregation root, resource pool and domain service to express, and organizes them into responsibility blocks called bounded context.
Entities are objects in the domain model that have a unique identity and do not change when the software state changes. Entities encapsulate state and behavior.
Value object is an object in the domain model, which is used to describe a domain driven aspect. It has no unique identity and is immutable.
Aggregate root is a type of entity that groups logically related sub entities or value objects together, controls their access, and coordinates their interactions.
Repository – responsible for receiving and preserving aggregate roots, generally using an object / relationship (ORM) mapping framework.
Domain services represent operations, behaviors, or business processes, and provide the ability to refer to other objects in the domain model. Sometimes, an aspect of a function or domain cannot be mapped to any object with a specific life cycle or entity. This type of function can be declared as domain service.
[Chapter 14] [design business workflow]
There are three basic workflow styles: sequence, state machine and data driven. For a sequential workflow, tasks migrate within a specified set of steps until they are completed. For state machine workflow, an activity is defined as a set of States and events, which will transfer an activity from one state to another. For data-driven workflow, activities are executed according to data-related information. Therefore, the first step in designing workflow components is to understand the workflow styles that you must support.
You can write workflows using code, markup language, or a combination of code and markup language. The approach depends on the needs of your solution authoring pattern.
WF provides a developer centric solution for creating sequences, state machines, and data-driven workflows. It supports pure code, code separation and markup mode.
It supports sequential, state machine and data-driven workflow, as well as code separation and markup authoring patterns.
Microsoft’s enterprise service bus (ESB) toolkit extends the functions of ActiveX, which focuses on how to build always connected, service-oriented applications.
[Chapter 15] [design data component]
The data layer component includes data access component and service proxy component. The data access component is used to access the data within the system boundary. The service proxy component provides access to its back-end system and exposes data through web services.
The data layer should use the data access infrastructure to coordinate all data source connections.
Whether it is encrypted or plaintext, do not save the user password in the database for future verification. You should save the password after using the salt value (specify a random byte for the hash value).
[Chapter 16] [quality characteristics]
The quality characteristics of an application, such as usability, performance, reliability and security, reflect the success of the design and the overall quality of the software application.
Each system attaches different importance and priority to each quality characteristic.
Delay refers to the event before responding to any event.
Throughput refers to the number of events that occur within a certain period of time.
The performance of an application will directly affect its scalability, and the lack of scalability will also affect its performance.
Scalability is the ability to handle extra load or increase load without affecting system performance. There are two ways to improve scalability: scale vertically (scale up) and scale horizontally (scale out). If you need to scale vertically, you need to add resources such as CPU, memory and disk to a single machine. If you need to scale horizontally, you need to add more machines to the farm running the application to share the load.
[Chapter 17] [crosscutting concerns]
Message based communication should be considered when crossing physical or process boundaries, and object-based communication should be considered in process (only crossing logical boundaries).
Message queuing can deliver transactional messages and support reliable one-time delivery.
The cached data should be kept as close to the cache as possible, which can reduce the processing and network round-trip process, and maximize the performance and application response speed.
[Chapter 18] [communication and message]
Decoupling components not only improves maintainability, but also improves flexibility, making it easier to change deployment strategies in the future.
Since each communication across logical or physical boundaries will increase processing overhead, it is necessary to design efficient communication by reducing round trips and minimizing the amount of data transmitted on the network.
If you need to interoperate with other systems, consider using XML serialization. But always remember that XML serialization has more performance overhead. If performance is critical, consider using two-level serialization because it is faster and the serialized data is smaller than the XML serialized data.
Consider using dto as a unit of data transfer instead of passing independent data types each time.
[Chapter 19] [physical layer and deployment]
For non distributed deployment, all functions and layers except data storage function are in one server.
For distributed deployment, each layer of the application is located in a separate physical layer. This layered mechanism organizes the infrastructure of the system into a group of physical layers, through which the specific server environment can be optimized according to the specific operational requirements and the use of system resources.
You need to remember that adding more physical layers increases complexity, deployment effort, and cost.
You can take advantage of techniques such as asynchronous calls, one-way calls, or message queuing to reduce blocking when calling across physical boundaries.
When designing a distributed environment, we must determine which logical layer and component will be put in which physical layer. In most cases, the presentation layer is placed on the client or web server; the service, business and data layers are placed on the application server; and the database is placed on a separate server.
When determining how to deploy components in a distributed environment, you can consider the following guidelines:
1. Distribute the components only when necessary. The common reasons for distributed deployment include security policy, physical constraints, shared business logic and scalability;
2. If the presentation component needs to use the business component synchronously, the business component and the presentation component can be deployed in the same physical layer to maximize performance and simplify operation management;
3. If there is a trust boundary between presentation component and business component for security, they can be deployed in different physical layers;
4. Unless there is a trust boundary between the service proxy component and the component calling the service proxy for security reasons, they can be put in the same physical layer;
5. Deploy asynchronous business components and workflow components in the same independent physical layer as far as possible;
6. Put business entity and components using business entity in the same physical layer;
If you are developing a client program that needs to access an application server, or a stand-alone client program that can access an independent database server, you can consider the two-tier mode.
For the three-tier design, the client will interact with the application software deployed on an independent server, and the application server will interact with the database on another server. For most web application services, this is the most common deployment mode, and can also meet the needs of most general applications. You may implement a firewall between the client and the web / APP layer, and another firewall between the web / APP layer and the database.
If the security requirements stipulate that the business logic cannot be deployed in the edge network, or the application code needs to use a lot of server resources, and you want to transfer the load of related functions to other servers, you can consider the four tier mode.
If the business logic cannot be placed on the front-end web server for security reasons, then we can consider using distributed deployment for web applications. We can use message based interface for business layer, and consider using binary coded TCP protocol to communicate with application layer to get the best performance. We should also consider the use of load balancing to distribute requests, so that requests can be processed by different web servers. We should also consider avoiding server affinity when designing scalable web applications, and designing stateless components for web applications.
For n-tier deployment, you can put presentation and business logic on the client, or just put presentation logic on the client.
“Vertical scaling” is to upgrade the running hardware, while “horizontal scaling” is to share the load by distributing applications to multiple physical devices. If you plan to scale horizontally, you will generally use load balancing strategy, that is, load balancing cluster.
Load balancing extends the performance of server based programs, such as web servers, by distributing client requests to multiple servers. Load balancing technology generally refers to load balancer, which receives requests and forwards them to a host when necessary. Load balancing hosts respond to different client requests concurrently, even if multiple requests come from the same client.
According to the routing technology, the load balancer may detect the invalid web server and remove it from the routing list, which can minimize the impact of failure.
If there is no need to track and save information between each client request, in other words, the communication is stateless, then the load balancing cluster is the most scalable and efficient. If you have to track state, you may need to use affinity techniques and session techniques.
In the development process, if you use Internet information services (IIS) version 6.0 or above, you can configure IIS as web garden mode to help ensure that the developed application correctly handles the session state.
Like web server and web farm, if the business layer, data layer and presentation layer are not on the same physical layer, the business layer and data layer can be extended horizontally by applying farm. Distributing requests from the presentation layer to every server on the farm has almost the same load. According to the demand of each layer and the load of the expected number of users, the components of business layer and data layer should be put into different application farms.
In general, if you want to extend your application, you can choose one or two of the two basic options to combine, which are “scale up” (to make the box bigger) and “scale out” (to use more boxes).
For “scale out”, add more servers and use load balancing and clustering solutions. In addition to handling the extra load, the “scale out” scenario can also alleviate the problem of hardware failure.
Vertical expansion with additional processors and increased memory is an economical solution. This solution can also avoid the additional cost of introducing “scale out” and using web farm and cluster technology. We should first consider the “vertical expansion” option, and check whether the “vertical expansion” scheme meets the established scalability standards through performance testing, and whether it can support the necessary number of concurrent users within an acceptable performance range.
If the “vertical scaling” of the solution cannot provide enough scalability due to CPU, I / O or memory bottlenecks, then it is necessary to “scale out” and introduce additional servers.
The loosely coupled layered design with clear remote interface is easier to “scale out” than the tightly coupled chaotic interaction design. Due to the inherent separation point of layered design, it is very suitable to “expand horizontally” at the boundary of the layer. The trick is to find the right boundaries.
[Chapter 20] [Select application type]
When choosing an application type, you need to consider the requirements, technical constraints, and the end user experience type.
Each application type can be implemented using one or more technologies. The use scenarios and technical constraints, as well as the ability and experience of the development team have an impact on the choice of technology.
RIA applications generally rely on a client-side plug-in or a managed execution environment (such as XAML runtime or Silverlight). The plug-in needs to communicate with the remote web server, which can generate the code and data needed by the client plug-in or execution environment.
[Chapter 21] [design web application]
When designing a web application, we consider using some technologies, such as caching and output buffering, to reduce the back and forth communication between the browser and the web server, and the communication between the web server and its downstream servers. A good caching strategy may be a very important performance related design point.
Authorization determines whether an authenticated identity can perform certain tasks and access certain resources.
You should use caching to optimize the lookup of reference data, avoid the overhead of network round-trip communication, and avoid unnecessary and repeated submission.
Use CSS to lay out as much as possible, rather than a table based layout.
Table based layouts are slower to render and have problems when layouts are complex.
Put the client script in a separate script file, which can be cached by the browser.
For the scenario of multi server (web farm), and session data must be centrally stored between servers, SQL server state storage is considered.
[Chapter 22] [design rich client application]
The user interface of rich client has the characteristics of high performance, high interactivity and rich user experience, and can adapt to independent, connected, occasionally connected and offline scenarios.
When designing a rich client application, the goal of the software architect is to select an appropriate technology, and then divide the tasks according to different content areas to minimize the complexity of the designed structure. The design must meet the requirements of application in performance, security, reusability and maintainability.
Sometimes, while all other aspects of an application perform well, a poor user experience can have a serious negative impact. So it’s very important to design your application to provide a compelling and intuitive user experience from the beginning, because the user experience is affected by many different aspects of your application architecture.
Use data binding function to display data as much as possible, especially for data in table format and multi row data. This reduces the amount of code required, simplifies development, and reduces code errors.
Windows Forms, WPF and Silverlight data binding all support two-way binding strategy, which allows data structure to be bound to a user interface component to display the current data to the user, and allows the user to modify the data, and then use the value entered by the user to automatically update the original data.
[Chapter 23] [design rich Internet applications]
RIA supports rich graphics and streaming while providing most of the advantages of web applications in deployment and maintenance performance.
[Chapter 24] [design mobile applications]
If you want to build a rich client, then the business layer and data service layer may be placed in the device itself. If you want to build a thin client, all layers should be on the server.
[Chapter 25] [design service application]
“Service” refers to the public interface that can provide a set of functions.
[Chapter 26] [design hosting and cloud services]
Cloud based services are usually divided into several types, such as storage / computing, business services, and retail / wholesale services.
[chapter 27] [design office business application]
Oba is an enterprise integration application.
Oba is designed to collaborate by using open standards, standard file formats, and web services.
[chapter 28] [design SharePoint lob application]
The application of SharePoint lob can be configured to publish Internet oriented content in the form of website, so that the website can be expanded with the deployment of web farm to support the access of a large number of users, and it can also interact with other users ASP.NET These websites are integrated to display lob data.