Data Service Architecture Issues

Currently relative to the project cache optimization, and then online to find information, there are a few questions to ask,
In general, our caches are handled on the business logic, such as:

The cache schema above has one drawback: business parties need to focus on both cache and DB,
Then we further optimize and join a service layer:

This scenario should be a mainstream solution, which provides a handsome data access interface upstream, shielding the underlying data storage details upstream, so that the line of business does not need to focus on whether the data comes from the cache or DB.
So the question: how is this service supposed to be implemented? Or what is the best solution?

Reply content:

Currently relative to the project cache optimization, and then online to find information, there are a few questions to ask,
In general, our caches are handled on the business logic, such as:

The cache schema above has one drawback: business parties need to focus on both cache and DB,
Then we further optimize and join a service layer:

This scenario should be a mainstream solution, which provides a handsome data access interface upstream, shielding the underlying data storage details upstream, so that the line of business does not need to focus on whether the data comes from the cache or DB.
So the question: how is this service supposed to be implemented? Or what is the best solution?

RPC, serialization of data and deserialization.

Large systems typically mix multiple programming languages, such as PHP for the front end, and Java for complex back-end computing and business logic, and some special services may use Erlang or C + +.
Then RPC uses the cross-platform language, Apache Thrift, or Zeroc ice is more convenient.

Service is written in robust languages that are easy to survive for long-term processes. Java is more appropriate. Application can be easily invoked, whether it be PHP or any other language.

Of course, you can also use contract data structures such as JSON to "serialize" and "deserialize" at each end.
Consider the high availability of the service layer, back-end calls to the problem, with a registration/discovery, heartbeat Health Check and other security can be. Self-development or use of zookeeper and the like are OK.

It is quite vague, because it is not specifically the specific question of the main problem is what.

