ios11修改微信步数_基于天宫的星舟微服务方案介绍

 微服务架构模式

面对单体架构带来的诸如应用更新周期长，无法针对单独的功能进行扩展和配置资源，无法弹性伸缩应用的负载能力，一个模块故障造成整个应用的不可用，难以采用新技术等等挑战，我们采用微服务架构模式来解决。微服务概念的提出者JamesLewis 和Martin Fowler对微服务的定义如下：

采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如RPC,HTTP(也就是REST)等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。

那么，引入微服务架构会带来哪些好处呢？

微服务将应用解耦，拆分出来的微服务组件可以独立部署，有更清晰的模块边界，每个服务提供方可以专注发布API，隐藏实现细节和版本。同时配合自动化工具，实现微服务的持续集成与交付，可以大大缩短迭代周期。

微服务按照业务边界划分服务，一个跨职能的团队完全掌握业务内的微服务，负责完整的端到端的开发和维护，团队更专注在一个服务上，可以更快更频繁地对服务进行迭代。

单体类应用扩展非常困难，业务耦合在一个进程当中，只能以单体应用作为部署的单元，无法针对某类业务进行水平扩展，浪费资源，灵活性较差。引入微服务，可以实现更细粒度的水平扩展，按需部署服务实例，节省主机资源，无需为应用常配峰值资源。

单体应用出现故障是非常严重的问题，而微服务强调服务的容错设计，允许服务调用出错，调用方在调用失败时不应该产生灾难性的结果。将业务封装在细颗粒度的服务当中，尽可能将故障限制在每个服务当中，不会因为一个模块的故障导致整个应用不可用，同时加上服务的熔断，降级等策略，有效降低应用故障风险。

微服务架构的挑战

微服务架构带来的好处可以有效解决目前cBSS遇到的问题，但同时也带来新的挑战：

微服务将应用拆分成多个独立的服务后，如何实现服务的注册发现，如何让多个实例服务的配置信息变更及时生效，如何对服务进行认证管理，限流控制以及负载均衡，如何将分布式部署的服务进行集中管理都是采用微服务架构模式后面临的挑战。

软件研究院微服务团队在采用微服务架构对业务应用进行微服务化时，着重解决API网关，服务注册发现，负载均衡，弹性扩缩容，服务熔断，限流降级，灰度发布，调用链分析等服务管理难题。

天宫与微服务容器化

基于天宫容器化平台，将微服务封装在容器当中进行管理，利用容器管理平台的特性，实现微服务的注册发现，负载均衡，弹性扩缩容，秒级启动，故障迁移，服务健康管理，灰度发布等功能。该套完整的微服务容器化解决方案经过cBSS大规模生产环境验证，形成了成熟的研发体系与支撑体系。

微服务熔断降级机制

同时，我们调研了开源的微服务管理组件，使用Netflix Hystrix实现服务的熔断降级，有效隔离故障，降低整体业务故障的风险，防止服务雪崩效应。

使用hystrix非常简单，首先引入在涉及远程资源调用的方法上添加@HystrixCommand注解，定义group、command、threadpool、fallbackMethod等属性，编写fallbackMethod定义的快速降级方法。

@Servicepublicclass WebServiceImpl implements WebService {    privatestaticfinal Logger logger = LoggerFactory.getLogger(WebServiceImpl.class);      @Autowired    private RestClient restClient;        @Override    @HystrixCommand(groupKey ="paylog", commandKey ="queryPaylog", threadPoolKey ="queryPaylogThread", fallbackMethod ="fallbackQueryPaylog", ignoreExceptions ={SkyArkException.class})    public List queryPaylog(String acctId, String starttime, String endtime, String provinceId){        //路径 /jdbc/paylog/{acctId}/{provinceId}        String[] uriPath =new String[]{"jdbc","paylog", acctId, provinceId};        Map<String, String> uriParams =new HashMap<>();//参数        uriParams.put("START_DATE",starttime);        uriParams.put("END_DATE", endtime);       RequestEntity requestEntity =new RequestEntity(uriPath, uriParams);        //服务间调用        Rsp rsp = restClient.callSkyArkMicroService(SysTypes.ACTING_CENTER,"sample", HttpMethod.GET, requestEntity);        if(SysTypes.STATUS_SUCCESS.equals(rsp.getRspCode())){            //查询成功，获取data节点信息            return rsp.getData();        }else{            //查询响应状态不是成功，则抛出业务异常(其他类型异常callCbssMicroService已封装)            thrownew SkyArkException(SysTypes.BUSI_ERROR_CODE, rsp.getRspDesc());        }    }    public List fallbackQueryPaylog(String acctId, String starttime, String endtime, String provinceId, Throwable e){        logger.error(e.getMessage(), e);        return Collections.emptyList();    }}

配置参数：在application.yml中添加如下default默认配置。

hystrix:  threadpool:    default: #对应@HystrixCommand注解中threadPoolKey的属性值，默认为default      coreSize:50 #线程池的核心线程数及并发执行的最大线程数      maxQueueSize:100 #最大排队长度     queueSizeRejectionThreshold:100 #即使maxQueueSize没有达到，达到queueSizeRejectionThreshold该值后，请求也会被拒绝。因为maxQueueSize不能被动态修改，这个参数将允许动态设置  command:    default: #对应@HystrixCommand注解中commandKey的属性值，默认为default      execution:        isolation:          thread:           timeoutInMilliseconds:1000 #执行超时时间      fallback:        isolation:          semaphore:           maxConcurrentRequests:1000 #任意时间点允许的并发数。当请求达到或超过该设置值后，其余请求不会调用fallback而是直接被拒绝

微服务依赖的底层数据库资源较多，如cbss的一个服务可同时访问8个域的oracle库，使用单个hystrix注解到方法上存在1个域的数据库异常占用整个服务的资源，最终导致整个服务不可用的风险。通常解决方法是重复定义8个相同的函数为每个函数添加指定的hystrixcommand注解，然后再函数调用前实现一个省份路由方法选择对应的域的函数执行。自定义路由资源隔离组件提供一套注解通过定义正则表达式匹配指定的路由字段选择其归属的线程池进行资源隔离，可用于解决上述问题。

此外，微服务一般都是多实例状态，我们使用Turbine实现多实例微服务hystrix聚合，就是把多个实例的/hystrix.stream，全部聚合在/turbine.stream中，通过Hystrix Dashboard中可视化查看。

API网关

引入API网关组件，将微服务的API管理集中化，解决了由于服务拆分带来的服务分散难于管理的问题，实现服务统一入口，提供客户端管理，服务调用量统计，服务限流，ACL规则，认证等功能，做到统筹一点管理。

KONG基于 OpenResty 进行 API 管理，运行在Nginx之上，采用lua脚本编写的插件进行功能定制。

KONG的三大核心功能模块是请求路由(Router)、负载均衡(Balancer)和集群数据同步。路由和负载均衡模块完全接管了nginx本身的策略，也是作为一个网关的核心功能。路由规则由HTTP主机头、请求URI和请求方式组成，规则匹配发生在Nginx的Rewrite/Access阶段中，access_by_lua_block指令块里面的kong.access()方法的前置handler中。集群数据同步则弥补了nginx集群管理的缺点，可以使得路由规则和负载均衡策略的修改可以动态进行，省去了修改配置文件和重启的流程。KONG的数据存储在数据库中，同时在缓存中保留一份。KONG的代码运行于nginx的worker进程中。KONG对数据的修改会在一个worker中进行，数据被修改后需要通知给本地的其他worker进程和其他机器上的worker进程，当数据库的中的数据被修改时，需要发出相应的事件通知其他worker。其他worker接收事件后，删除缓存中对应的数据。下次从缓存读数据时发现没有的话，就从数据库加载出来。

KONG的部署可以选择容器化部署，首先创建一个数据库cassandra或者PostgreSQL，用来存储路由配置，服务配置，upstream 配置等信息。

部署KONG的容器，启动命令：

export KONG_NGINX_DAEMON="off"&& kong migrations bootstrap && kong prepare -p /usr/local/kong/&& /usr/local/openresty/nginx/sbin/nginx -c /usr/local/kong/nginx.conf -p /usr/local/kong/

将微服务route的API注册到KONG：

注意点，以上配置将调用KONG在8001的/apis实现微服务接口注册，uris指定该api在KONG上访问时的uri路径，当有多个时使用逗号分割，upstream_url为KONG转发的下游，可以为域名或ip。

通过KONG访问服务，查看请求头信息可以看到kong的相关信息：

微服务的持续集成与交付

无自动化不微服务。自动化包括测试和部署，单一进程的传统应用被拆分为一系列的多进程服务后，意味着开发，调试，测试，监控和部署的复杂度都会增大，必须要有合适的自动化基础设施来支持微服务架构模式。而容器快速启动和镜像仓库天生是为CICD设计的，以前我们启动一个虚拟机需要几分钟，而启动容器只需要几秒钟，有了这种能力以后集群式的和并行的持续集成与交付才能成为可能。我们在工作实践中引入持续集成与交付并引入容器化技术，从提交变更代码到部署天宫总共耗时在分钟级别，极大提高软件开发迭代效率。持续交付将微服务镜像提交给天宫的组件仓库中，具备可随时安装部署与更新。

我们使用jenkins作为持续集成实现工具，把jenkins运行在天宫上，jenkins-master与jenkins-slave均为容器化，jenkins-master可以在构建时根据实际需要向天宫申请slave节点资源，构建完成后将资源归还，jenkins-master的数据持久化到磁盘上，即使jenkins因意外崩溃后重启仍然可以恢复任务数据。配置Jenkins-slave参数：

Jenkins通过gitlab的webhook实现代码更新触发自动化构建。Jacoco插件和sonarqube相结合可以实现代码单元测试覆盖率等。通过Jenkins打包完成后，我们自研发构建脚本，将微服务的jar生成可运行的docker镜像并上传镜像仓库，生成可安装的天宫组件包并上传到天宫组件仓库。构建项目配置示例：

微服务管理与运维

微服务将应用拆分，这样做的副作用就是，运维和监控随之分解到每个服务里，失去了作为整体管理的优势，性能数据难以收集，难于进行故障排查。

我们从点，线，面三个维度对微服务进行监控管理。

点：CPU，内存以及服务状态数据；

线：端到端的数据，并在每个节点关联点的状态数据；

面：一组微服务提供的整体业务的资源使用情况，运行情况，如负载与容量。

服务接口管理

经过拆分后的微服务种类繁多，调用关系复杂。微服务管理平台将微服务的组件包信息、契约信息、网关信息、资源信息、hystrix信息、gotty入口、日志级别等集中化管理，使开发者或运维管理者对已上线的微服务接口信息一点看全，提高接口复用率，发现微服务故障或接收到业务报错告警后，紧急联系相关负责人员。

服务状态监控

       DCOS平台只提供对容器性能的简单监控，对其上运行的微服务并不能提供很好的监控能力，因此，在调研了Netflix开源的hystrix组件后，我们在微服务中增加了熔断降级的机制，同时实现了对微服务状态的监控与展示，其中包括服务吞吐量，处理时延，错误率，熔断状态，线程池状态等信息。真正实现监控由设备走向业务。

服务调用链监控

我们在联通内部首次引入PinPoint开源技术，实现了服务调用链的分析，以拓扑图的方式展示服务间的调用关系以及每次调用过程的详细信息，实现从点到线的监控。

pinpoint主要由以下三部分组成：1、pinpoint Agent，在微服务的VM option加入Agentid、applicationName，就可以加入一个探针，agent代码注入技术，当一个类被加载的时候会通过 Interceptor 向指定的方法前后注入 before 和 after 逻辑，在这些逻辑中可以获取系统运行的状态，并通过 TraceContext 创建 Trace 消息，进行数据的抽样采集，数据包括agent本身的一些信息，内存，线程信息还有trace信息；2、pinpoint collector，收集agent发来的数据，并将数据存到Hbase中；3、pinpoint web，数据展示图形化界面，便于调用链监控信息查询。

Pinpoint消息的数据结构主要包含三种类型 Span，Trace 和TraceId。这三类数据均在http header中在微服务调用链上传递。基于agent在不侵入代码的基础上能修改http header并在调用链上传递的特征，我们组实现了灰度发布的http header在调用链上透传，使全链路上所有微服务可以无差别使用httpheader灰度发布。

整体业务情况监控

利用API网关的集中管理能力，采集API网关调用的日志，以服务API的维度统计微服务平台的访问量以及时延，出错等数据，更加直观的反映整个微服务平台的健康状态，以及每个API的服务质量，实现一点看全。

微服务容器化平台成果

中国联通软件研究院自2016年7月起，开始建设基于容器化技术的微服务平台，将现在cBSS1.0单体应用进行微服务化改造。截至2019年1月，微服务平台共上线服务717个(容器1258个)，外部服务每日调用量约6580万次，峰值调用量1705+/秒。在集群资源扩展，应用部署效率，应用扩展能力，发布周期以及升级策略上都有明显的提升和改善：