网站开发组合 lamp,彩票网站有人做吗,网页制作与设计书籍心得体会,电影网站做淘客王者荣耀 去年我有幸被老领导邀请以系统架构师的岗位带技术团队#xff0c;并对公司项目以微服务进行了实施。无论是技术团队还是技术架构都是由我亲自的从0到1的选型与招聘成型的#xff0c;此过程让我受益良多#xff0c;因此也希望在接下来的系列博文尽可能的与大家分享… 王者荣耀 去年我有幸被老领导邀请以系统架构师的岗位带技术团队并对公司项目以微服务进行了实施。无论是技术团队还是技术架构都是由我亲自的从0到1的选型与招聘成型的此过程让我受益良多因此也希望在接下来的系列博文尽可能的与大家分享我的经验。 古人有云将军难打无兵之仗。想要把微服务很好的实施也并非能一个人可以完成的事一来需要有出色的运维提供支持二来需要花时间做技术选型与攻关三来还要开发兄弟们配合实施。因此这次能顺利实施并不是一个人的王者而是团队的荣耀。 框架源码https://github.com/SkyChenSky/Sikiro 文末有说明工欲善其事必先利其器 以上是我们公司的技术栈点击图片可在浏览器打开除了统一配置中心没有服务器资源和Hangfire还没场景使用外其他都已经上线使用了。 俗话说得好工欲善其事必先利其器。一个优秀的工程师应该善于使用框架和工具在微服务这一块的技术栈选型并非一蹴而就也是我多次对比验证后并良好的集成到公司项目然后落地实施。这系列框架单纯这么去用其实是可以无缝集成的但是在落实项目的时候我为了集成得更加友好和使用上更加便利在基础上做了扩展例如SkyWalking添加Request和ResponseCAP与Chloe.ORM的集成等下文我会逐个分享。 有需要的朋友可以参照我这套去实施这样大家就可以花更多的时间把精力放在业务、调优、拆分、设计等方面。 此外大家看得出我所有的技术栈基本上找的都是开源社区的比较出名的项目没有一个属于自研的。这样做的原因 快速搭建 降低成本 社区支持维护 利于人才引进 其实可以看出.Net不缺优秀的开源项目那么实施这么久让我唯一觉得深刻的印象是缺少整合。 之前我也跟不少同行讨论过甚至在面试的时候他们觉得应该自己造一个轮子原因各种各样但唯独缺少了希望在开源项目基础上完善下这个原因。我也理解他们的心理因为“优秀”的工程师应该自己写一套证明下自己。其实我认为这也许是包容心的在作祟我们应当求同存异学会接受已经检验过的轮子在基础上完善您的需要有必要还可以给社区做贡献双赢。原则 我做技术选型的时候坚持着三大原则简单、适合、运维优先。 在满足需求的情况下优先选择轻量级的框架因为轻量级总比重量级的易学习易于扩展易于理解源码。试想一下有个框架什么都很齐全但是学习曲线高在写一个demo的时候各种踩“坑”找原因还有可能出了问题不知道怎么解决除了开始你初认识该框架觉得他很厉害之外后面使用每走一步都是阻碍和吐槽。 在有限的资源、人力、时间我们更新技术的同时还要保证业务的正常开展我会优先选择我比较熟悉的技术我会将他们进行封装、优化、集成尽可能的减少开发人员对技术细节的认知负担尽可能以他们最熟悉的使用方式提供。此外我们团队是有运维岗如果问题由运维解决更快、更方便则优先交给运维尽可能让开发关注数据流转与业务流程。 PS我选型的时候不是一蹴而就的下文可能我会提到某些框架工具我没有去选择原因并不是否认它们存在的价值而绝大问题是这些不适用于我们团队。最后我向伟大的开源项目与其作者致敬。 微服务 有一条盛传于我们行业的公式软件 程序 软件工程。 程序就是我们经常产出的算法、数据结构、脚本、框架、架构等。 为什么称之为软件工程因为这是具有科学方法论引导的、多人协作、有明确目标、有阶段性的。从以前瀑布开发再到10年前盛行的敏捷开发最后到最近几年流行的DevOps可见开发模式也随着技术架构更新也不停的演进。我们团队选用了原型模式DevOps模式来应对我们的微服务架构的开发。 书本的教条主义我就不多说了我对微服务的理解分为微和服务。微 如何微微到什么程度我借助两样东西合理的系统架构分层与DDD思想两者分别管理架构的纵向拆分与横向拆分。 架构分层我采用了前后端分离多层架构自顶向下的依赖各司其职。 DDD在最近几年非常流行然而这并非新的技术十几年前就已经它的出现了。随着微服务盛行DDD的划分域的化繁为简的思想与微服务的本质-拆不谋而合因此DDD也随之热门起来。 下面是我们的架构图这个话题在下一篇重点再讨论。服务 我接下来用一段话描述一下服务化的需要。首先API网关作为我们请求流量的入口隔离了外网与内网的作用。接着开发人员得知道如何调用服务那么可以从注册中心发现已注册的服务的IP地址、端口的列表这就是服务的注册与发现接着我们需要知道服务下接口路径、请求与响应的格式因此我们需要服务描述。满足前面两个条件后我们就可以进行调用服务了因此我们需要RPC框架进行服务通信。当服务运作后我们需要服务监控来监控服务的运行情况以此方便调优。随着服务拆分得越细、跨度越大服务出问题的时候不容易定位因此我们需要服务跟踪进行问题定位。 由上述可见组件主要包括以下6点 API网关 服务描述 服务注册中心 RPC框架 服务监控 分布式链路跟踪API网关 API网关主要起到了隔离内外网、身份验证、路由、限流等作用。我用一个生活的例子搭地铁比喻来描述下过闸前我们需要经过安检保证客流的安全性上下班高峰期还会排队进行限流我们还可以通过看指示牌或者询问工作人员了解到应该往什么方向走这就是路由。 我们团队选型了Kong和KongA作为我们的API网关Kong是一个在Nginx运行的Lua应用程序由lua-nginx-module实现。Kong和OpenResty一起打包发行其中已经包含了lua-nginx-module。基本功能有路由、负载均衡、基本认证、限流、跨域、日志等功能其他功能例如jwt认证可以通过插件进行扩展。 有人会问为什么不用Ocelot回答这个问题之前我首先声明我尊敬Ocelot项目与其开发者。 1.易用性。需要二次开发虽然对.Net开发者来说能接受但不利于运维。 2.性能。社区很多测试数据据我了解就是kong 11KOcelot 3.5K四舍五入3倍性能差作为流量的入口性能这块我还是比较注重的。 3.可扩展性Kong很多功能可以通过插件式按需使用与开发。 服务描述 我们团队采用了Swagger以此来衔接前后端开发的接口对接省去了编写接口文档的成本此外也支持接口调试让开发效率提高不少。我们的服务都是以HTTP协议提供对外API用RESTful风格对内统一以POST的RPC风格提供。服务注册中心 服务注册服务在发布后自动把IP地址与端口注册进服务中心服务发现通过调用服务中心的接口获取到某服务IP地址与端口的列表。我们团队选用ConsulConsul TamplatenginxConsul是基于GO语言开发的开源工具主要面向分布式服务化的系统提供服务注册、服务发现和配置管理的功能。Consul的核心功能包括服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等特性。 Consul作为服务注册中心的存在但是我们服务发现只能拿到IP列表我们使用RPC调用时还是得做负载均衡算法于是使用了Consul Tamplate把服务列表同步到nginx的配置那么RPC框架就无需集成负载均衡算法经过nginx路由。 开始选型我并没有选择Consul Tamplate而是选择了fabio的这个中间件。fabio是一个应用于Consul的轻量级、零配置负载均衡路由器开始用的时候部署起来很方便、很简单。后来上了Skywalking分布式链路跟踪系统只要经过fabio路由的都无法把调用链串起来虽然将就的用是没什么问题但是Skywalking的调用链日志无法很好的展示出来就会影响日后的问题排查。我当时花了两天时间研究与issue提问并没有很好的结果所以最后另外选择了Consul Tamplatenginx。服务通信 RPC框架主要三大核心序列化、通信细节隐藏、代理。协议支持分TCP和HTTP当然还有两者兼容集成MQ的。我们选择了WebApiClient做客户端服务端仍是.Net Core WebAPI主要考虑到WebAPIClient的轻量、易用而且和Skywalking、Consul集成方便。我当时用的时候时.Net Core 2.2版本gRPC并没有集成进来。 此外我也选择过ServiceStackServiceStack的技术栈很全缺点是依赖得很深当时试用的时候它所以依赖的一个底层包ServiceStack.Common的某个类与WebAPI冲突了所以对于不熟悉该框架的我断定存在依赖污染无论我需要还是不需要都统统依赖进来了然而我只是希望要一个简单的RPC框架。此外还需要破解。 Surging也作为我当时选型的目标开始也是我抱着最大希望的因为描述得很牛逼什么都是全得。然而深入去用的时候没有一个完整的文档入门demo也不友好说实话我驾驭不住只能放弃。服务跟踪 市面上的分布式链路跟踪系统基本上都是根据谷歌的dapper论文实现的基本上都分三大块UI、收集器、代理探针原理大概是把涉及的服务链路的RequestID串起来。 我们团队选择了SkyWalking作为了项目的分布式链路跟踪系统原因很简单易用无侵入集成良好。 实施到我们项目的时候我做了点扩展把Reqeust、Response、Header、异常给记录了下来并过滤了部分不需要记录的路径。分布式事务 只要在分布式系统分布式事务必不可缺。分布式事务分类理论案例中间件强一致性ACID二阶段提交msdtc最终一致性BASE本地消息表CAP 本地消息表是eBay在N年前提出的方案而CAP以该思想实现的一门框架原理大概是本地业务表与消息凭据表作为一个事务持久化通过各种补偿手段保证MQ消息的可靠性包括MQ正常发布与消费。 我花了多天的时间专门测试了该框架可靠性的确有保证。然而有个地方我认为可以优化Retry的查询语句条件可以更加严谨点只需要负责相应的Group进行Retry就好没必要全部都查询出来因为这个问题我在测试环境与本地环境共同调试时刚好两个环境的Group不一致导致会Retry失败的问题。框架源码 写到这里本篇的分享差不多要结束了我将开源我们公司的工具库有需要的朋友可以去使用。 Sikiro.Tookits -公共基础库 Sikiro.Nosql.Redis-StackExchange.Redis的基本封装 Sikiro.Nosql.Mongo-mongodb驱动封装更新、排序等支持lambda Sikiro.MicroService.Extension-RPC注册,微服务框架-服务注册,终端跟踪忽略 Sikiro.Chloe.Extension-支持多数据、事务封装、分页、IOC Sikiro.Chloe.Cap-把Chloe,ORM与CAP整合 额外说明下DotNetCore.CAP.MySql这个是我从CAP源码拷贝过来然后改了MySql.Data的依赖原本CAP.MySql是用的MySqlConnector和我的Chloe.ORM冲突了。
