编者按：前2月，向朱攀兄弟约稿，畅聊甚欢，引为知己。今刊发以飨读者！
微服务为当今群雄混战局面，从dubbo问世数载，然业界尚未有完整打包结局方案，前有小剑之《老司机带你玩PPmoney微服务》，德比软件作为前驱，集数年研究与实战，搭建平台，填埋深坑，则业界之幸！
适逢1024程序员节，一并祝各位程序猿/媛节日快乐，早日步入老司机行列
数据对接平台的架构?体上分三个层次，最外?是 API 层，由 API Gateway 和各业务的 API 服务组成，中间层是服务层，平台的?部分的功能在这层实现，服务之间通过依赖或组合，可以组成功能更强的服务，最底层是存储层服务，由缓存层和存储层组成。
数据对接平台采?微服务架构，为了?撑这个架构，我们提供了必要的基础设施来保障上层各个服务和应?的可?性。
德比软件微服务架构基础设施
如图所示，我将我们的基础设施分为了??部分，分别是服务框架、基础服务、 API ?关、?动化、服务降级、监控 警、?志处理和调?链追踪。其中服务框架、基础服务、 API ?关和服务降级是为了提?服务的连续?作时间；?动化为了简化开发和部署过程；监控 警、?志处理和调?链追踪是为了快速发现问题，定位问题并解决问题。
API 关 DGateway
服务框架
服务框架分两部分，高可用的 RPC（Derbysoft-RPC）和服务依赖管理。
上?的服务依赖是不是很乱们的服务节点分布在全球 14 个可?区?，?部分在 AWS 上，?部分在?建的私有云?，可?区之间的服务有复杂的依赖关系。为了解决这种情况下服务之间的依赖调?问题、 API 安全问题和服务的?可?问题，我们设计开发了路由服务，解耦服务的调?者和提供者，简化?络拓扑图，简化服务器的安全配置。引?路由之后，服务之间的依赖关系简化为如下图所示：
基础服务分四部分，分别是配置中心，安全数据服务，数据存储服务，订单服务。基础服务大多和存储有关，提供高性能高可用的服务。
微服务化后，服务的数量很多，为了节约开发成本，必须尽可能的自动化完成一些有固定步骤的工作，如测试自动化和部署自动化。
微服务化后，服务的数量很多，为了节约开发成本，必须尽可能的?动化完成?些有固定步骤的?作，如测试?动化和部署?动化。
（1）测试?动化
单元测试?动化，我们?前要求单元测试覆盖率要求?于90%，通过 Jenkins 整合 Sonar，每次提交代码后?动跑单元测试， Sonar ?动给出代码评分，测试覆盖率不够或代码不达标，则单元测试失败；
性能测试?动化、平台化，我们开发了?动化测试平台 DTesting，关键服务的每次变更，需要在平台上跑性能测试，并?成性能测试 告，对?历史的性能测试数据；
功能测试?动化、平台化，每个应?都有完整的功能测试?例和脚本，可?动化回归功能测试
（2）部署?动化
我们引?了 Docker，减少?为部署时的误操作。
日志处理
很多情况下，解决故障可能很快，难点在于发现故障和定位故障，这需要我们的系统有全?位的监控和 警能?。基于业务和技术对可?性的需求，我们开发了服务健康状态监控和 警系统，从业务层，服务层，硬件基础设施层分别进?监控和 警。
警
警系统定义所有 警种类， 警级别，处理流程，提供 警接?机制，各个层次的监控都可以通过?定义 警引擎接? 警系统来触发 警。 7 * 24 ?时服务监控团队会根据各个 警的处理流程，依次联系最?优先级的处理?来处理故障，如果在规定时间没有处理完，系统会根据 警的种类和级别?动升级 警响应级别，提?处理优先级来保障重要的 警能得到及时处理。
有了服务健康状态监控和 警系统，辅以调?链追踪系统和?志处理系统，我们发现和定位故障的时间就?较可控了，绝?部分故障可以很快定位原因，为修复故障提供了有?的保障。
发布管理
最后我想说说发布管理，虽然它不属于基础设施，但是它太重要了，对服务的高可用影响很大。基础设置都做到位了就万事大吉了吗，还差一口气，还需要确保最后一公里万无一失，那就是服务的发布管理，最后一公里主要规划以下三点。
（1）容量规划，通过测试 告评估应用的类型，是IO密集型、CPU密集型还是混合型据应用的类型，申请合理的硬件资源；单台节点最大处理能力是多少上有多少容量正在被使用群的最大处理能力是多少些在发布前都需要合理的评估和测试。
（2）冗余规划，需要考虑异地多可用区部署，服务实例不小于 N+2 部署，服务实例硬件配置需相同，避免大小不一部署实例。为什么是 N+2 而不不是 N+1 呢了防止在服务更新的时候同时又挂掉一个服务节点，而发布失败是高概率事件。
（3）发布控制，线下充分测试，能在线下做的测试绝不不能放线上做。刚才说了，发布失败是高概率事件，所以发布必须要支持回滚，必须拒绝一切没有回滚方案的更新，嗯，是必须拒绝。
写在最后
微服务系统本质上是一个分布式系统，而分布式系统就有其固有的复杂性，对测试，部署甚至团队的组织结构都会带来很大挑战。有了这些微服务架构的基础设施，能有效帮我们解决并规避一些问题，但我们仍然不能低估采用微服务架构带来的复杂性。微服务架构不是银弹，更不是免费的午餐，实施微服务改造是要付出代价的，根据业务的需求选择合适的架构，不要为了微服务而微服务。
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树使用JDBC操作数据库数据库操作91411 人正在系统学习中 相关资源：今目标软件(桌面今目标)09/26-专业指导文档类资源-CSDN文库
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！