这个问题我就结合着自己的项目来说一说。
我们现在的项目是没有前台页面的，只对外提供接口服务，甚至我们项目都没有交易类的服务，都是单纯的查询类服务。项目最初的建设目标就是为了缓解核心系统数据查询的压力，或者你们可以把我们项目看成几个核心项目的缓存层(因为有多个核心系统，我们项目还可以提供跨系统的查询，这一点也很重要)。
打铁还需自身硬，要提高接口的稳定性和响应速度，首先代码要写好：
我们项目采用了关系型数据库做中间库，数据经过加工后落地到mongodb和redis，对外的提供的服务，只会查询mongodb和redis；
数据加工很重要，关系型数据库中需要多表关联的查询，现在只查询mongodb的一个collection就可以了。（因为要做数据加工，所以数据和生产库比，有一定的延迟，这个一定要看业务场景是否允许有延迟）；
mongodb采用副本集分片的部署，副本集保证数据库的稳定性，挂掉一台，还有其他几台可以使用；分片保证数据量增大后，可以平行扩容。（现在数据量大概在亿级，个位数）；
服务部署还采用比较传统的，n台服务器前面挂负载均衡；上各种监控，随时关注接口调用和资源使用情况；
严格的参数校验，避免做无用的查询；
大原则就是：【能查缓存就不要查数据库，能不查的话就更好】
除了自身架构之外，还有些非自身的控制：
内部系统在调用接口的时候，主要通过网络权限的控制，除此之外不做任何的限制，包括鉴权；
如果是互联网端的接入，还是需要依赖网关；由网关做鉴权、限流、降级、熔断等；
参与对方系统功能的设计（这一点很神奇），因为大多数时候都是公司内部的系统，所以在做需求讨论的时候，最好能看一下对方系统的调用场景；很有可能调整一下什么时候调用接口，就能大大减少接口的调用次数；
建议调用方设置合理的超时时间，并有合理的重试机制；
如果可以的话，最好可以采用异步调用的机制；
如果接口要依赖于另外系统的接口，也需要额外的做一些考虑（依赖的接口返回慢或者报错，自己的接口肯定会有问题）；比如数据时效性要求不高的话，可以考虑把对方接口返回的数据缓存下来（设置失效时间，保证一段时间后能把最新的数据刷新回来），但如果数据时效性要求非常高，可以考虑使用熔断；不过说实话，还没见过谁敢用熔断的....
希望我的回答，能够帮助到你！我将持续分享java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
优化数据库大幅度提高oracle的性能
几个简单的步骤大幅提高oracle性能–我优化数据库的三板斧。
数据库优化的讨论可以说是一个永恒的主题。资深的oracle优化人员通常会要求提出性能问题的人对数据库做一个statspack，贴出数据库配置等等。还有的人认为要抓出执行最慢的语句来进行优化。但实际情况是，提出疑问的人很可能根本不懂执行计划，更不要说statspack了。而我认为，数据库优化，应该首先从大的方面考虑：网络、服务器硬件配置、操作系统配置、oracle服务器配置、数据结构组织、然后才是具体的调整。实际上网络、硬件等往往无法决定更换，应用程序一般也无法修改，因此应该着重从数据库配置、数据结构上来下手，首先让数据库有一个良好的配置，然后再考虑具体优化某些过慢的语句。我在给我的用户系统进行优化的过程中，总结了一些基本的，简单易行的办法来优化数据库，算是我的三板斧，呵呵。不过请注意，这些不一定普遍使用，甚至有的会有副作用，但是对oltp系统、基于成本的数据库往往行之有效，不妨试试。
.jpg)
.jpg)
.jpg)
.jpg)
