昊蓝_个人页

需要的，在微服务的上层，需要有一个应用层，负责业务逻辑处理，它提供前端访问的rest接口，同时，它也调用下面的各微服务的接口完成业务逻辑封装。

根据实际服务器的内存来定义，建议JVM maxheap设置为服务器内存的一半，如果服务器内存为8G，建议jvm堆空间为4G。

可以使用jstat、jmap、jstack命令来查看jvm内存分配和使用。

1.服务拆分要合理2.服务治理3.服务流控4.服务依赖5.服务容量6.服务容错

服务粒度的划分：服务粒度划分很难有统一的标准，当服务粒度过粗时，服务内部的代码容易产生耦合，多人开发同一个服务带来开发成本的增加；当服务粒度过细时，服务间的层次结构会更复杂，编码时往往需要去对多个服务进行修改才能完成一个需求。阿里内部通过实践总结了三个划分原则供参考：首先是服务依赖层次不超过三层，即A依赖B、B依赖C、则C不应该再依赖于D，如果出现了多层依赖或循环依赖，需要审视当前的服务划分粒度。再有就是研发团队规模，一个服务系统建议不超过3个研发人员维护，避免大量人员集中修改公共代码带来效率的下降。最后是系统代码规模，过多的代码可能需要系统拆分或服务更细粒度的拆分，提供一个经验值，单个服务系统的代码行数在3万行左右比较合适。

问题发生后，第一时间是快速保留问题现场供后面排查定位，然后尽快恢复服务。保留现场的具体操作：打印堆栈信息，命令行：jstack -l 'java进程PID'打印内存镜像，命令行：jmap -dump:format=b,file=hprof 'java进程PID'生成core文件，命令行：gcore 'java进程PID'保留gc日志文件保留业务日志文件查看JAVA堆内存运行分配：命令行：jstat -gcutil 'java进程PID' 1000完成以上操作后，尽快重启JAVA进程或回滚，恢复服务。当应用系统运行缓慢，页面加载时间变长，后台长时间无影响时，都可以参考以下归类的解决方法。绝大部分的JAVA程序运行时异常都是Full GC、OOM(java.lang.OutOfMemoryError)、线程过多。主要分这么几大类：持续发生Full GC，但是系统不抛出OOM错误堆内存溢出：java.lang.OutOfMemoryError：Java heap space线程过多：java.lang.OutOfMemoryError：unable to create new native threadJAVA进程退出CPU占用过高通常来说，可以用一些常用的命令行来打印堆栈、内存使用分配、打印内存镜像文件来分析，比如jstack、jstat、jmap等。但是某些时刻，还是需要引入更高阶的代码级分析工具（比如btrace）才能定位到具体原因。针对每一种问题，我会依据具体的case来详细说明解决方式。

建议使用mybatis，另外JPA也是可以的。