从组件到(微)服务服务器引擎部-王奎什么是组件•定义:•组件(COMPONENT)是对数据和方法的简单封装。•模块:•(MODULE)是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。完成特定通用功能的程序集合组件VS模块•组件和模块都用于指代一组函数或函数的一部分。模块更多是逻辑性的,例如:ERP系统中的财务模块,HR模块,制造模块......另一方面,组件更具有物理性。在软件中,它可以是一个DLL,OCX,EXE,...•没有标准来衡量哪一个大于另一个。一个组件可以包含模块列表,一个模块也可以包含许多组件。组件用于在技术视图中对系统建模,模块用于在功能视图中对系统进行建模(系统的功能)模块是特定系统中的逻辑组成部分或业务功能的集合WHYCOMPONENT•基于组件的软件工程(COMPONENT-BASEDSOFTWAREENGINEERING,简称CBSE)或基于组件的开发(COMPONENT-BASEDDEVELOPMENT,简称CBD)是一种软件开发范型。它是现今软件复用理论实用化的研究热点,在组件对象模型的支持下,通过复用已有的组件,软件开发者可以“即插即用”地快速构造应用软件。这样不仅可以节省时间和经费,提高工作效率,而且可以产生更加规范、更加可靠的应用软件。“organizationswhichdesignsystems...areconstrainedtoproducedesignswhicharecopiesofthecommunicationstructuresoftheseorganizations.”任意一个软件都能反映出其制作团队的组织结构,这是因为人们会以反映他们组织形式的⽅式工作–M.Conway做一件事需要特定的组织结构组织的结构也会反映到产品中去组件与组织组件设计原则-SRP•单一职责原则(SRP)•一个类应该仅有一个引起它变化的原因。•类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。•变化的原因(AREASONFORCHANGE)。•如果你能够想到多于一个的动机去改变类,那么这个类就具有多于一个的职责。•而单一职责原则正是反映了《代码大全》中所说的:软件的首要技术使命--管理复杂度,而找出容易变化改变的区域,隔离变化,就是一种很好的管理复杂度的启发方法。会呼吸的鱼组件设计原则-OCP•开放-封闭原则(OCP)•对于扩展是开放的(OPENFOREXTENSION)•对于更改是封闭的(CLOSEDFORMODIFICATION)ClientServerClientinterfaceClientInterfaceServer组件设计原则-LSP•子类型(SUBTYPE)必须能够替换掉它们的基类型(BASETYPE)•正方形是一个矩形•IS-A关系是就行为方式而言的,IS-A的含义过于宽泛以至于不能作为子类型的定义。子类型的定义是“可替换性”ISP接口隔离原则•任何层次的软件设计如果依赖与不需要的东西,都会是有害的User1User2User3OPS+OP1+OP2+OP3DIP依赖反转原则•如果想要设计一个灵活的的系统,在源码层次的依赖关系中就应该应用抽象类型,而非具体实现•C++多态•C++20CENCERPTS虚函数•慢的原因•多了几条汇编指令(运行时得到对应类的函数的地址)•影响CPU流水线•编译器不能内联优化(仅在用父类引用或者指针调用时,不能内联)REP(TheReuse/ReleaseEquivalencePrinciple)复用/发布等同原则软件复⽤的最小粒度应等同于其发布的最小粒度CRP(TheCommonReusePrinciple)共同复用原则不要强迫一个组件的用户依赖他们不需要的东西CCP(TheCommonClosurePrinciple)共同闭包原则将哪些会同时修改,并且修改目的相同的类放到同一个组件中,反之就应该放到不同组件中组件设计原则-目的设计一个网络组件•需求:•接口简单•单线程应用•多平台支持•可靠性•高性能GNET组件设计底层平台完成度EpollLinux高IOCPWindows中AsioAll中KqueueMac中LibuvAll中LibevLinux中LibeventAll低用户关心什么•直观问题•创建连接对象•释放连接对象•事件:建立连接,收到数据,发送数据,连接关闭•潜在问题:•事件回调是否同一个线程?•发送是否线程安全?•断包问题?•性能?多线程•多线程•CPU多核•快!=吞吐量•多进程(此组件不在此粒度)•用户可以使用此组件做分布式系统造芯片的家伙们正忙着生产那些大多数程序员不知道如何编程的多核CPU发送数据•强制要求单线程?•内部句柄暴露给用户安全吗?Send(fd,buf,bufLen);单线程逻辑层•应用层不需要复杂的线程同步•业务逻辑太多,同步数据过多,导致性能低下•容易出问题•组件集成还是应用实现?多线程使用场景•状态无关业务:•解码过程比较费CPU•心跳数据•转发数据包•有状态服务•用户状态•游戏交互逻辑等N转1队列•并发技术•互斥锁•信号量•条件变量•原子操作•内存序核心思想:减少冲突简单实现跨平台•平台差异•LINUX下EPOLL(LT/ET)•MAC下KQUEUE•WINDOWS下IOCP•LIBEV/LIBEVENT/LIBUV接口设计-KISS原则•KEEPITSIMPLE&STUPID•KISS原则是指产品的设计越简单越好,任何没有必要的复杂都是需要避免的。•用户只关心他需要关心的KeepItSimple&Stupid;KeepItSweet&Simple;KeepItShort&Simple;KeepitSimple,Sweetheart;KeepitSimple,Sherlock。最容易的莫过于忙忙碌碌,最困难的莫过于卓有成效。KISS≠专业性•稳定性•系统需要考虑极端情况下的处理•负载平衡(LOADBALANCING)是一种计算机技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。使用带有负载平衡的多个服务器组件,取代单一的组件,可以通过冗余提高可靠性。负载平衡服务通常是由专用软件和硬件来完成。主要作用是将大量作业合理地分摊到多个操作单元上进行执行,用于解决互联网架构中的高并发和高可用的问题。•高低水位:•设置系统边界,避免局部崩溃,提升组件鲁棒性•木桶原则•短板原则,即一个木桶装多少水,不是取决于最长的那块木板,而是取决于最短的那块木板。•BETTERISBETTER组件的劣势•能解决我的全部问题吗?•区分不同消息类型?•能实现N:M线程模型吗?•我不要发送缓存区可以吗?•能适合全部领域吗?•我可以不用C++11吗?•能跑在ANDROID/IOS平台?•我的GO/PYTHON/NODEJS程序能使用吗?•我不会C++,能用吗?组件只是尝试以合适的的方式解决特定领域的特定问题组件只是一部分•网关需求:•高并发网络处理•数据转发•会话管理•广播处理•多登陆处理•。。。BUG无处不在•自身BUG•BUG无处不在•使用限制•使用不当导致错误路径•风格不合•萝卜白菜,各有所爱•就不想用•。。。IT’SOK组件介绍GROUTERV1解决服务器分布式设计难问题,通过分布式算法保证数据的一致性,解决AKB服务器分布式设计需求。Gateway1Gateway2GatewayNRouter1Router2Game1Game2Game3解决akb服务器分布式需求开发的分布式组件,接入此组件后项目组只需关注上层逻辑,通过组件分发消息,简化逻辑编程。目前已接入使用GROUTER特性1一致性23可用性高性能通过分布式锁实现对象的定位Router缓存对象位置(二级缓存)目标服务器不存活重新定位多个对称Router形成的集群,集群化部署10Wqps的转发,800到1000的定位GROUTER发展目标:将grouter发展为分布式服务器核心组件,使游戏服务器架构设计更简单,更清晰01、将Router和Gateway合并,减少一次消息转发与游戏网关合并,减少消息转发将组件加入到核心服务器上优化算法03020102、将分布式定位算法移植到Game上,支持更灵活的分布式程序开发03、用multiraft协议实现分布式锁,替代etcd,提高现在对象定位的速度GDBV2•使用简单:•简化的FORMAT语法:{FMT}•一句话SQL执行:•简化V1版本底层依赖,使用更容易•大幅提升项目组数据库服务器开发效率sql.select(uid,name).from(user_info).get([](ResultSetPtrres){});XML2CPP•一键生成配置代码•1.配置模板文件GATEWAY.XML.EXAMPLE•2.执行命令:XML2CPP--FILE=./CONFIG/GATEWAY.XML.EXAMPLE--OUT=./CONFIG•3.生成./CONFIG/GATEWAY.XML.H和./CONFIG/GATEWAY.XML.CPP共享内存组件跨平台组件丰富数据结构支持运行时守护支持windows/linux平台使用封装了标准库常用组件,头文件库无依赖,方面使用在服务器异常时保证数据不丢失,服务器快速重启,玩家不掉线。特性:1.逻辑和数据分离,运行时数据更安全2.基于共享内存的数据守护进程,保证服务器异常情况下快速拉起3.头文件库,丰富数据结构支持,简单易用目前业界比较流行的提升服务器稳定性主流方案为什么需要微服务•多语言架构:•各类语言各有优劣,C/C++高性能,GO开发效率高•硬件及软件发展推动服务器整体性能提升•软件系统越来越大,代码越来越多,结构越来越复杂•云化的发展,服务都通过云的方式提供•人才的层次结构也反映了服务的分级实现•更多的互联网技术,开源项目推动了专业化发展什么是微服务•微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。微服务特点•通过服务实现应用的组件化(COMPONENTIZATIONVIASERVICES)•独立替换和升级的软件单元,在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。•围绕业务能力组织服务(ORGANIZEDAROUNDBUSINESSCAPABILITIES)•微务架构采取以业务能力为出发点组织服务的策略,因此微服务团队的组织结构必须是跨功能的(如:既管应用,也管数据库)、强搭配的DEVOPS开发运维一体化团队,通常这些团队不会太大微服务特点•产品而非项目模式(PRODUCTSNOTPROJECTS)•传统的应用模式是一个团队以项目模式开发完整的应用,开发完成后就交付给运维团队负责维护;微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期,倡导“谁开发,谁运营”的开发运维一体化方法。•智能端点与管道扁平化(SMARTENDPOINTSANDDUMBPIPES)•微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中,通讯机制或组件应该尽量简单及松耦合。RESTFULHTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。微服务特点•“去中心化”治理(DECENTRALIZEDGOVERNANCE)•整体式应用往往倾向于采用单一技术平台,微服务架构则鼓励使用合适的工具完成各自的任务,每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。•“去中心化”数据管理(DECENTRALIZEDDATAMANAGEMENT)•微服务架构倡导采用多