1. Interface definition
1. Distinguish business-level exceptions and system-level exceptions.
System level exception: throws an exception
Business-level exception: return a different business code
----In this way, it is possible to distinguish whether it is system-level or business-level according to the exception.
a): For http interface, return such as: {"sysCode":0,sysMessage:"success",busiCode:0,busiMessage:"",result:{}}
sysCode==0 is system-level success, other values are system-level failure, and system-level failure is not limited to business return values.
busiCode==0, the business is successful. For other values, the business fails.
This method actually has three levels of status codes:
1. httpstatus==200 , the http request is successful
2. syscode== 0, the system executes successfully (no exception)
3. busiCode==0, business-level execution is successful
The above three steps are successful, and then take the result value.
b): For rpc interface:
1. If the calling interface is not abnormal, it means that the system executes the function
2. The return value object busiCode==0, indicating that the business level is successful
The above two steps are successful, and then take the result.
2. Return value: The interface is called multiple times, and the returned data structure and semantics must be consistent.
If the return value is a json, and this json has 100 attributes in full, then no matter whether these 100 attributes have values, they need to be returned.
If only values with values are returned, then when the data changes (a property changes from no value to a value), the data format returned by the interface (the number of properties in json) is inconsistent with the previous one (more than one property).
2. Timeout problem
1. After a service has determined the host environment and related databases, redis, etc., the highest tps it can handle is basically determined.
Use the stress test to measure the highest tps of a single service, take 60% of the tps as the warning value, and calculate the current tps of the online service in real time.
When the early warning value is reached, an alarm is issued to expand the number of services and relieve the pressure.
It is to know how much work the service can do, not more than that.
2. Similarly, for the database, when the environment is determined, test its maximum tps, and use 60% of the tps as the early warning value, so that the problem can be known in time, and the host or sub-database with better performance can be replaced for the database.
3.
3. Data verification
After the new application is launched, the data will be scanned regularly at the initial stage and checked against business rules. It is possible to find abnormal data and application problems.
4. Monitoring
1. Request quantity change monitoring
2. Online timing request returns correct result monitoring
3. Application port monitoring
4. Host monitoring
5.
1. Interface definition, clear input parameters, return values, various states of return values
2. Unit testing, covering various situations of return value
3. Layering: interface layer, cache layer, business logic aggregation layer, module function layer, DAO layer
Each layer should be described with interfaces as much as possible
4. Distinguish strong and weak dependencies,
Strong dependencies: success or fail fast,
Weak dependency: go asynchronous without affecting business threads
5. Database tables: split large tables into small tables, query by index, and try not to do table association queries
6.MQ consumption service, independent deployment
7. Stress test: average response time in milliseconds
8. Online automated testing--verify online business availability