1）     目前比较简单，通过token授权，无名加密，无appid和serect秘钥授权之类的。故而没有较强的安全机制，但是能够满足实际开发。而且目前的公司业务对于安全的要求并不高。

2）     通信性能不高，因为目前采用Http协议进行通信，本身通信性能不高。而且认证中心将承载所有业务的认证，基本上所有云项目模块等业务都会将请求汇聚到认证中心的接口上，在后续公司流量的发展上必然会出现第一个出现接口上的性能问题。

未来方向：

1）     平台所有的接口实现内部必须有redis缓存，平台接口客户端使用要有sdk封装（在sdk内部做客户端缓存，哪怕默认5 s的缓存）

2）     平台的所有接口后续接到“高性能服务中心”，走TCP连接池的通信方式实现，提高内部通信的性能。

4）     服务中心（个人开源地址：）

公司现状：

1）     项目之间出现互相调用的业务耦合，目前采用dll的方式调用，但是出现dll更新出错及管理等情况，导致开发人员认为效率不高。

2）     公司迫切希望采用微服务/soa的架构方式来剥离项目的业务耦合，简化上下游业务调用的管理方式。

采用方案：

1）     暂时采用Http restful类似的方式提供服务化的接口，供第三方接口调用，同时这也符合soa服务化的架构思想。

2）     通过api view 自动公开接口文档，上下游之间调用调试，方便开发人员沟通协调。

方案弊端：

1）     个人经验：服务化的接口方式有效的,对业务沟通也是非常有帮助的，但是未必能够真正的在效率上得到本质的提升。但是对于项目的模块化管理应该有较好的帮助。

2）     Http的接口通信方式效率并不高，作为服务框架必然是走TCP的内部通信，性能才会有明显提升。

3）     服务治理，协调方面的问题为考虑，如没有考虑调用链死循环，调用链上的性能导致雪崩，上下游服务监控，上下游客户端服务变更历史记录及通知，上下游客户端服务协议耦合剥离，服务化层面的负载均衡和故障转移等等众多问题。

未来方向：

1）     自研服务中心，将性能，服务治理，协调等工作从业务开发中抽离抽象出来，业务开发只需要关注无状态的业务服务开发即可。

2）     所有内部的业务全部剥离（不仅仅是耦合的业务），迁移到内部的服务中心，如果内部服务需要对第三方公开，可以提供Http的开放网关服务进行调用，网关层会做一些授权管理等工作，网关自身做负载均衡。

5）     统一监控（个人开源地址：）

公司现状：

1）     项目处于前期研发阶段，没有较大规模的服务器集群，没有遇到多版本接口兼容，没有遇到线上监控问题和线上排查问题，性能问题的痛苦，对这些情况还不了解和敏感。

2）     开发人员希望解决项目开发调试时候，错误日志及错误日志的堆栈问题，调用路径问题排查。

采用方案：

1）     采用Http Restful 服务化业务接口的方式，应该能缓解项目开发调试的问题。（开发调试问题以前没遇到过，应该跟原来架构和技术采用wcf等方式有关导致）

2）     搭建分布式监控平台，因为是本人已有开源的项目，使用起来问题不大。能够解决很多云上服务器管理，性能监控及预警，sql性能监控，api接口性能监控，统一错误日志等。

方案弊端：