问题背景 随着软件开发技术架构的不断演进，采用诸如TSF微服务框架开发微服务已经成为一种趋势，然而随着客户业务流量的不断提升，微服务也会遇到性能上的瓶颈，对于系统如果做到高效、 性能优化需要解决如下问题： 降低业务成本。 提升系统的稳定性。 提升用户的体验。 单体应用优化：关注单系统瓶颈，通过解决单系统瓶颈提升性能。 多应用全链路优化：通过改造链路结构和配比进行整体性能的优化。 一、单体应用优化实践 1、确定性能瓶颈。 可以帮助我们开发者在极短时间内快速构建微服务系统。 image.png 对于小型企业的业务，通过进行较为简单的单系统优化，并辅助结构性优化，便能满足大部分企业的要求，但随着企业的业务量不断增加，单独的单机优化已经不能满足需求。
因此有三个层次： ① Action层可能出现解析请求参数、返回结果有问题； dao【如果在这里报错了，一般都是比较致命的，我们先不管】 ② Service 层则可能出现请求中要做的业务操作出现问题；出现了问题要根据实际情况判断是否会影响本次操作结果 这里写图片描述 ---- 自定义异常类 总的系统异常类 /**** * 这是我们自定义的总系统异常类 * * */ public class SysException extends Exception } public SysException(Throwable cause) { super(cause); } } Action异常类 继承着我们自定义的总系统异常类 public class ServiceException extends SysException { public ServiceException() { super("操作业务失败了
提供包括云服务器，云数据库在内的90+款云计算产品。打造一站式的云产品试用服务，助力开发者和企业零门槛上云。
关于服务化，以及软件系统的服务化，是一个大的概念。我通过写这些以服务化为主题的文章，总结出来服务化是一种思想，是一种软件过程，并没有严格的非此及彼的标准化定义. “服务化是有一定的量化指标可以参考的 本文试图在软件开发理论与中小型软件项目的最佳实践的基础之上，探寻最大程度的软件系统服务化。 “服务化系统首先应该是分布式的系统。 有如下几个可量化的属性 “共享性 1 服务化的系统最终功能交付物被多个下游系统依赖调用，调用方>=2。也就是一个服务是可以被多个服务消费方共享使用的。服务需要独立部署，不需要与其他项目深度耦合。 我们需要定义系统的核心模块及数量，也就是服务化的粒度 “稳定性 3 服务化的系统要稳定，可靠，可控 “健壮性 4 服务化的系统具有一定的健壮性，弹性。对于异常可以进行平行过度，拥有降级等容错机制。 弹性思维 弹性是服务化系统的一个特点，要求系统在遇到异常和外部破外时，能够保持原有最小化的功能输出，不至于被压倒。设计者在设计服务系统时，需要建立弹性思维。 ? 弹性思维 容错降级 ?
：设计微服务系统 这是关于可视化微服务的三部分博客系列的第二部分。 既然被接受的理解系统的方法是关注它的组件之间的关系，那么如果我们想要一个微服务系统的基本表示，我们就不需要比上下文映射更深入。因此，也许我们可以使用DDD上下文映射作为可视化表示微服务系统的起点。 客户和卡片管理 支持客户信息，客户认证和基于卡的授权申请与新的支付服务最为接近的应用程序。 存款账户 支持存款账户的记录和发放系统（审核，储蓄）授权和实现以客户为中心的付款所需的信息的系统。 例如，存款账户上下文只包含一个存款账户服务。整个服务系统现在看起来像下面这样： [j1a65bq8cb.png] 这个设计过程的最后一步是为将发生在服务之间的交互添加注释。 关于这个微服务系统有几点需要注意。首先，不要假定在为终端用户活动提供服务时，这些交互中的每一个都会实时发生。
•engine：服务引擎，这个可以理解为一个真正的服务器，内部提供了多个虚拟主机对外服务。 •服务(service)：一个服务组件通常包含一个引擎和与此引擎相关联的一个或多个连接器。给服务命名可以方便管理员在日志文件中识别不同服务产生的日志。 并发优化 最大线程数 最佳并发数。。。 底层优化 JVM优化 多实例（必须的） 操作系统优化 JVM优化：固定堆内存，多线程并发收集，对象预留新生代，大对象进入老年代，启用内联 多实例：多个tomcat实例在一台机上 操作系统优化：网络参数， 7. client_header_buffer_size 4k;客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小
2.2 流量控制，按服务分配流量，避免滥用 相信很多做过高并发服务的同学都碰到类似事件：某天A君突然发现自己的接口请求量突然涨到之前的10倍，没多久该接口几乎不可使用，并引发连锁反应导致整个系统崩溃。 同理我们的接口也需要安装上“保险丝”，以防止非预期的请求对系统压力过大而引起的系统瘫痪，当流量过大时，可以采取拒绝或者引流等机制。具体限流算法参见《接口限流实践》一文。 a）计算算法优化 如果服务需要进行大量的计算，比如推荐排序服务，那么务必对你的计算算法进行优化，比如笔者曾经对地理空间距离计算这一重度使用的算法进行了优化，取得了较好的效果，详见《地理空间距离计算优化》 b）初始化java集合类大小 使用java集合类的时候尽量初始化大小，在长连接服务等耗费内存资源的服务中这种优化非常重要； c）使用内存池/对象池 d）使用线程池的时候一定要设置队列的最大长度 之前看过好多起故障都是由于队列最大长度没有限制最后导致内存溢出 ，具体参考《lucene索引文件大小优化小结》一文。
在实际应用开发过程中，我们的应用复杂性没有达到一定规模时，应用程序只涉及到客户端 APP 和服务器端中心云服务的认证和业务处理。我们可以对 OAuth2.0 协议进行简化，演变为两方 OAuth。 sign-token.png 设计要点 采用前后端分离，将接口参数分为系统级别参数和业务级别参数。 系统级参数主要包括 app_key,timestamp,token,os_type,sign，主要置于 HTTP 请求头位置。业务参数基于业务需求，采用 POST 或者 GET 方法按需传递。 下文中罗列一些这种设计的优势 识别终端 使用 App-Key 的方式识别应用终端，企业内部不同的应用，由云端服务统一管理。 伴随着业务发展，可以逐步演化为基于三方身份的 OAuth 协议工程实现。 Token 机制和签名机制也可以 独立分层，与业务应用分离，演化为网关系统。
CORS 是一种浏览器协议，源于 HTTP 请求的安全策略，在这个体系中的关键词有，同源策略，XMLHttpRequest，Ajax，和前后端分离。 “CORS 协议的实现需要客户端和服务器端配合协作完成。也就是我们通常所说的跨域设置。 这种方式是服务器端安全防范的一种。 $message); exit(); } 通过 Access-Control-Allow-Headers 设置自定义字段的方式，是一种安全策略，服务端要求请求头必须携带 我们常说跨域设置是客户端和服务器端一起配合的结果，官方协议更倾向于让开发者对于跨域无感知，而浏览器与后端服务的交互和相互信任是核心。
共存，切换，兼容 系统中涉及到服务商对接模块的，设计之初必须考虑多服务商的共存，切换，兼容。 这里的服务商包括 推送系统的推送服务商，极光，信鸽，sms短信服务商，开票业务服务商，呼叫中心服务商等。 这类服务商提供的服务，可以理解为SAAS服务。 ? 解决方案稳定吗？ 要实现共存，切换和兼容有几个问题需要考虑 业务字段兼容 现在行业服务商对接都是服务接口方面的对接，json数据结构，http协议这些是行业共识了。 索然协议有共识，但是实现细节各式各样，每个供应商对于接口的实现不同，同一业务含义的字段表示不同，遇到这一问题如何解决？ 分清对接方和服务方 解决这一问题的核心切入点是以哪个系统为主。 这里的系统包括对接方业务系统和服务方开放系统两类。 优先推荐以业务系统字段描述为主，在对接开发时做字段映射来实现。 实现以自我业务系统为主的设计之后，可以进而实现切换和多服务商共存。
1.1 查看Linux版本 1.1.1 系统版本 [root@znix ~]# cat /etc/redhat-release CentOS release 6.9 (Final) 1.1.2 内核版本 [root@znix ~]# uname -r 2.6.32-696.el6.x86_64 1.1.3 系统架构 [root@znix ~]# uname -m x86_64 1.2 添加用户、设置密码 g' /etc/selinux/config 让配置文件的修改生效，使用source命令 [root@znix ~]# source /etc/selinux/config 永久修改的配置生效需要重启服务器 使用的服务器不可以随意重启！ [root@znix ~]# echo $LANG en_US.UTF-8 1.7.2 查看远程软件的字符集 连接软件的字符集是否与系统的一致 1.7.3 乱码解决办法 1） linux系统字符集修改
概述 在Linux 学习笔记一大体介绍了一些简单的Linux知识和一些简单的优化。 精简系统自启动和删除无用的账号和组 在安装Liunx系统中有很多服务、用户或者用户组都是无用的，通过安全和性能考虑需要删除或者禁用他们。 针对不同的服务和应用来优化Linux内核，比如针对Apache和Nginx等来设置优化Linux内核，如果针对Oracle设置相应的设置Linux内核优化。 如果没有特殊的要求可以不用设置自己的Linux内核优化。我们下边设置的内核参数主要是适用于Nginx，Squid等web服务。 在优化之前，我们通过命令查看当前连接统计数： [brian@Master ~]$ netstat -n | awk '/^tcp/ {++S[$NF]} END{for(a in S) print a
1、内核优化 ECHOSTR='net.ipv4.tcp_fin_timeout = 2 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4 65535 3、更新yum源，安装epel源 vi /etc/yum.repo.d/CentOS-Base.repo 略 yum install epel-release -y 4、系统时钟同步 disabled#g' /etc/selinux/config setenforce 0 fi systemctl stop firewalld systemctl disable firewalld 调整系统字符集
服务 Diagostic policy server 检测网络 禁用 print Spooler 打印机 禁用 Superfetch 加速了固态硬盘的寿命损耗禁用, 机械键盘自动 Windows Defender 禁用 Windows Update 禁用 Windows Search 文件索引 修改 虚拟内存 环境变量的用户变量和系统变量的 temp和tmp路径改为D盘 删除分辨率、小工具、个性化具体路径： HKEY_CLASSES_ROOT
useradd -m WHO #新建用户，并在/home下创建相应目录 $ passwd WHO #设置passwd 分组、权限等可自行查找 2、源文件（更新源，以cenos 7为例） 对于CentOS 7系统更新 更新之前备份原有的源（mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup ）；之后按照上面的命令下载对应系统的阿里云源 undefined 有人说yum clean all是个坑：在Centos7系统中执行yum clean all之后，发现yum的其他执行都报错了；要解决，关键在这里：把/var/cache/yum/ error" 进一步判断错误类型 error 1：There are unfinished transactions remaining 使用yum-complete-transaction清理未完成事务
推荐系统怎样稳定高效提供服务，持续不断满足业务需求，持续不断面对技术挑战，是每一个服务端开发同学应该持续思考，和持续不断优化线上服务。 ? 为了应对大型机构，特别是大型电子商务系统，需要持续不断优化，将单体程序进行横向纵向拆分，每个组织只维护自己的服务，每个模块可进行不断持续的升级优化，微服务将系统拆分，整个系统复杂度降低，并且每个系统部分 当下个性化推荐系统面临问题和一般程序有一定差异性，一方面个性化意味着“千人千面”，每个用户用到数据都不一样，常规缓存策略失效，这就要求对程序不断优化已保证性能。 ，品类分隔优化用户体验，这是原来常规逻辑。 把线上素材特征召回集一下子由200扩大到1000，性能一下降到400ms，性能不可接受，经定位分析发现耗时为计算服务，怎么样才能优化GBDT模型计算性能呢？
1、调度器调优？？ image.png 读请求高于写请求 image.png 请求合并 image.png -Anticipatory参数 image.png image.png -CFQ参数 -NOOP参数 4、文件系统调优 image.png XFS文件系统调优 image.png image.png image.png image.png 5、网络调优 6、内核参数调整： socket缓冲区大小：/proc image.png 9、消息队列相关参数： image.png msgmni推荐128B 10、共享内存相关参数： image.png 调整信号量参数例子： image.png 11、代码调优： gcc -p //取得目标代码中的概要信息 -o1/2/3 //数字越高，调优越高
一、使用show variables 和show status 命令查看MySQL的服务器静态参数值和动态运行状态信息。 九、innodb_support_xa 是否支持分布式事务，默认支持。 十、innodb_log_buffer_size 日志缓存大小，设置一秒的所需内存空间。
作者：Zane Blog 来自：http://luojinping.com/2017/08/13/服务调优/ 1. 服务异常的处理流程 ? 2. 所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法 的代码都在非堆内存中。 服务指标 4.1 响应时间(RT) 响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。 4.4 QPS每秒查询率(Query Per Second) 每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量 从以上概念来看吞吐量和响应时间是衡量系统性能的重要指标，QPS虽然和吞吐量的计量单位不同，但应该是成正比的，任何一个指标都可以含量服务器的并行处理能力。
企业出行服务系统（BMSS）为拥有车源的出行平台或车企服务商提供完整的企业出行服务系统。通过企业出行服务系统，出行平台不仅可以线上化管理用车企业客户，还可以为客户提供行业前沿的商务用车方案。
扫码关注云+社区
领取腾讯云代金券
云服务器
测试服务 WeTest
文件存储
命令行工具
SSL 证书