中台辨析：架构的演进趋势（4）
对于Vernon举的例子，由于没有更多的信息，因此无法进行详细的比较，但是EBA的数据建模中，子实体的概念也可以满足不同领域的需要；Richardson举的Order的例子，在EBA方法中，很可能不会仅设计成一个庞大的Order实体，而是会拆分出客户、地址、付款单等多个数据实体，至于最后Order实体会剩多少个属性，就要看实际情况了。但是Order这个例子中，更重要的一点是，EBA方法确实有可能会朝着设计一个中央Order数据库的方向前进，因为很可能将其定义为一个Order业务能力组件，供各类业务应用进行调用，这是企业级业务能力复用的一种体现。至于这个例子中，Richardson提到的“紧耦合”问题，其实并非是Order服务变动会引起其他服务变动，而是其他服务需要修改Order模式时，会引起Order服务变动，这在EBA中，也是会出现的问题，这个问题是要辩证的看，也即，在集中设计Order业务能力组件获得的好处和引起的耦合之间进行取舍。综上，我们可以看到，EBA可以与DDD方法进行适当的结合，但是也有在数据模型、企业级抽象目标方面的矛盾，设计方法结合的实践者必须思考操作上需要注意的问题。如果能够有效地实现EBA与DDD结合，那对于DDD而言，找到了从企业战略分解到DDD设计的整体引导方法；对于EBA而言， DDD则对提升组件或者构件的设计效率有一定帮助。这方面的结合已经有了不错的探索者，华为的朱如梦老师写过一篇专门探讨结合方式的文章《业务架构——跨领域的统一语言》，有兴趣的读者可以参阅。（三）EBA与微服务其实EBA与微服务之间，笔者觉得交集主要就是在软件架构设计上，说的更直接点儿就是服务拆分上。微服务在技术实现方面自有一套落地方法，而且有Netflix成功的大规模实践。尽管通讯机制导致的复杂性也让很多人头痛不已，但是相比服务拆分这种很难找到标准的事情，还是要相对好些，所以，微服务才出现了与DDD的结合，二者都是想在一个限界上下文中，找到能够适合为之设计独立数据库的一组行为。EBA在落地层面也需要微服务这类可以提供较大灵活性、复用性、伸缩性的实施方式，如果结合的好，二者都能够相得益彰，EBA同样也可以解决服务划分问题，而且还附赠战略落地服务。EBA方法笔者在书中曾有个改良设计方法的建议，就是吸收2003年提出的构件理论在EBA解决方案中引入构件的概念，以“乐高”积木为目标设计功能模块，这些功能模块可以成为微服务设计中需要定义的服务。微服务的局限性之一就是该方法比较适合重构，很难在一个系统的初期设计中找到合适的设计思路，因为，微服务事实上代表着对业务更深刻的理解和精炼，实际上，笔者提出的构件设计方式也很难用在系统的首次设计上，这一点二者倒是很相似。说到二者的矛盾之处，主要也是操作层面，类似消除“上帝类”这种对企业级抽象的不同处理思路，微服务以追求服务尽可能高的“独立性”为目标，但是实践中，耦合通常都很难完全消除；EBA更看重的是对业务能力的聚类，尽管“高内聚、低耦合”也是其设计目标，但是聚类过程中，其实比微服务设计方式更容易出现耦合问题。对于真实开发工作而言，如何处理耦合问题还是要从实际出发，不能“一刀切”地论其好坏。（四）EBA与敏捷开发EBA与敏捷的关系，笔者在书中曾经论述过，主要是针对“敏捷宣言”的内容。按照多数读者的第一印象来讲，恐怕都会认为EBA这种“漫长”的实施过程与敏捷主张的开发过程“格格不入”，这一点在EBA首次设计时更为明显，坦白地讲，笔者并不认为这一阶段适合敏捷，因为认识和改变一个企业的整体架构，注定是一个需要深思熟虑的过程。敏捷开发针对的是“瀑布模型”，但是EBA并非“瀑布模型”，它是一个对企业当前状态的刻画过程，是寻找企业战略落地措施的方法，应该说，二者是不同问题空间的解域，直接比较二者并不一定合适。此外，敏捷开发崇尚的是“轻文档”而非“无文档”，Martin Fowler认为敏捷注重的是演进式设计，而不是轻视设计；Vernon也批评一些敏捷开发实践是用“任务板挪卡”代替了设计；Sutherland在“OODA”循环中也强调掌握全景信息而非只从自身视角看问题的重要性，每次Scrum结束提出MVP，都要重走一遍循环，因为MVP就是为了获得更多、更全的反馈信息，有了这些信息才能快速决策，快速决策绝非快拍脑袋，是因为有模式加速了对信息的处理速度，这才是敏捷的原动力，也是要总结方法论的原因，“全景信息+思维模式=快速决策”。“OODA”循环如图10所示：与敏捷比，EBA确实是个“慢悠悠”的工作，思考的深度决定EBA的价值，因此，不给予充分的时间开展的EBA工作，无异于是在浪费时间。没必要试图用敏捷的思路去加速EBA过程，当今社会更缺乏的反倒是对企业级问题的“慢”思考。EBA解决方案诞生后，敏捷方法可以用来促进EBA的落地过程吗？答案是肯定的，但是要让业务架构师参加到敏捷团队中，解释、修改EBA解决方案，这样才能确保实施团队充分理解作为实施前提的EBA解决方案。USPTO的例子也说明了EBA在确定任务优先级方面的作用，这点对敏捷而言也很重要。敏捷的周期很快，这也意味着，如果结合不好，那实施效果偏离原定解决方案的速度也会很快。（五）小结：多歧路EBA与“组合拳”的关系暂且论述到这里，总结一下：EBA最大的优势在于为“组合拳”提供企业层面的总体设计指引，这不是为了整体而整体，是为了实现整体性而整体，有了这个指引，才能更好地发挥“组合拳”的功效。但是，方法之间并非没有冲突，结合之路需要慎之又慎，如果我们当前无法像物理学家那样追逐“大一统理论”，那就让我们像Sutherland创立敏捷方法的初衷那样去实践，“当我着手开始建立Scrum时，并没有打算创造一套新的流程。我只是想汇总一下之前几十年里关于最佳工作方式的研究成果，看看都有哪些最佳做法，然后借鉴过来，效仿一下”，这其实是个很轻松的说法，知易行难。三、聊聊中台（一）“水深火热”的中台“中台”概念的缘起大家都清楚，来自马云先生对一家欧洲游戏公司考察后的感悟，一个比喻。实践层面，钟华老师写的《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》是第一本比较完整地阐述阿里巴巴中台实践过程的著作，可以说是中台布道的开始吧，钟华老师如今仍在实践其理念。2019年中台可谓火的一塌糊涂，既有从原产地阿里巴巴出来的创业团队，也有将其原有实践简单包装冠以中台名号的“贴牌”者。去年在的一次交流中，笔者曾经用Gartner曲线的形式，串起了与中台相关的书和文章，与参会者开了一个小小的玩笑，如图11所示：彼时还没有那篇炸了圈儿的文章，笔者也无意将其补进去，毕竟这张图也只是个玩笑。任何技术形态都会经历这个历程，架构理念也不例外。有价值的自然会重新走回上升态势，哪怕是10年以后，或者像AI一样几起几落；没价值的也就寿终正寝了。Richardson 也说过：“人们往往容易被情绪因素所驱动，这也是为什么会有这么多关于技术的两极分化和过度粉饰的争论”。中台就其设计理念而言，仍是为了有效降低系统设计复杂度、提升复用能力的企业架构方法。去年南京中台大会的闭门讨论中，主持人曾要求每位演讲嘉宾用一句话概括自己对中台的认知，笔者当时说的也是“跟我实践过的EBA相似，也只是一种架构方式”，确实，就目的而言，二者殊途同归，都是在考虑识别、沉淀企业的业务能力，将其模块化、服务化之后，更好地支持业务变化。EBA与中台的差别，在实操层面也许主要是EBA并未考虑要将沉淀的业务能力剥离为中台层，因为EBA主张企业级复用，从这个角度讲，也不需要单独进行一个特殊的表达。EBA形成的业务组件之间按照调用的频率也可以适当进行分层，但这种分层结果并非现在中台的含义。除此之外，中台目前对企业战略如何分解落地也没有很详细的解释方法。阿里巴巴也是业务架构理念的实践者，业务架构根据其设计范围可以区分为领域级和企业级，阿里巴巴对业务架构的应用，从其自身披露信息来看比较侧重于领域级，业务架构师按领域配置和开展工作。当然，设计发展到一定程度，总是会自然关注到企业级。对中台的探索，笔者认为仍然值得开展下去，无论它以后还叫不叫中台，这是对架构设计理念的探索。从阿里巴巴的角度看，也是他们在技术底层实践越来越成熟之后，对上层设计的必然追求。笔者也不太赞同按照企业规模去给中台划个准入门槛，毕竟企业无分大小，只要系统建到一定规模或者数量，时间累积到一定程度，总有“技术债务”要还，总有重构的十足理由，那么作为一种架构设计理念去应用中台方法，未尝不可。如果说到成本，规模小的企业当然不必仿照阿里巴巴的方式构建昂贵的基础设施，设备成本是由系统的非功能性需求决定的，与企业的规模、财务能力也是匹配的，所谓中台烧钱，可能主要是想照搬阿里的技术方案造成的吧。抛开这个，它与一般的重构相比，是否真的会大幅度提高重构成本，笔者还是怀疑的。至于进行业务梳理的成本，只要企业想改革，这个成本无论用任何方法都是要付出的。玄难和毗卢离职前，阿里的中台计划取名为“星环”，据说名称创意来自于刘慈欣老师的《三体》，是那艘超光速飞船的名字，对于快的追求不言而喻。但是从笔者的角度来看，倒是更喜欢美剧《无垠太空》中的“星环”，每个“星环”都是通向一个世界入口。企业自建中台需要自身的沉淀，中台产品提供商则需要行业沉淀，现实中，还需要对行业中处于不同位置或者细分领域的客户进行不同分类的沉淀，如此看，中台就像“星环”一样，是通向不同世界的入口。如果愿意再揶揄一下，走进入口，遇见的可能是“天堂”，也可能是“地狱”。EBA也可以成为“星环”，道理是一样的。通过EBA也可以不断积累对行业或者细分领域的模型，这些模型不仅对架构设计者有所帮助，而且可能是未来走向自动化设计、AI设计的必经之路，因为AI也需要架构数据的供给才能产生设计能力，而目前架构领域连案例都经常是语焉不详、光怪陆离，更不说积累数据了。（二）中台与“组合拳”其实中台与“组合拳”的关系，阿里巴巴的人自己出来多讲讲会更好。从笔者的了解来看，阿里巴巴的中台实践中，“组合拳”的应用是不少的，他们的特点是一般不会强制团队使用某种方法。微服务显然是广泛使用的，敏捷开发、DDD在不同的团队中也都有应用，但是，应该不是每个团队在每次开发中都采用这些方法。阿里巴巴的中台，据说在大规模构建之前面对的问题之一就是企业已经有上万个微服务，每次承接新需求都可能有数百个微服务受到波及，而服务数量如此之多，以至于没有人能搞清楚业务能力到底有哪些、是如何分布的，所以，搞起了业务架构，分离业务领域，理清不同领域的业务模式，再沉淀业务能力，形成中台。微服务是中台在技术层面落地的方式之一，但是中台设计要有效地为微服务的划分提供指导，并从架构层面提供业务能力的可视化，进而支持业务能力的持续优化，通过架构演进指导微服务的设计与变化。微服务则在技术落地上提升对业务能力的运维支持，提供良好的升级维护和可扩展性。在分离业务领域方面，DDD方法也有一定范围的使用，毕竟这种方法与微服务的结合被广泛传说，而且DDD的思维方式就是侧重对限界上下文的分离，以达到在同一个限界上下文内对同一业务概念理解上的一致。每年Thoughtworks的大会上，也都有阿里人来分享应用DDD的经验。至于敏捷开发，更是常被当作互联网企业的标配。中台跟“组合拳”的关系，其实也应该类似于本文第二部分中讨论的EBA跟“组合拳”的关系，只是现有的信息中，中台并没有像EBA那样给出一个明确的设计过程和方法，所以，分析也很难做的更深入，这并不是对着几张漂亮的架构图就可以做的比较。
中台辨析：架构的演进趋势（3）
二、企业级业务架构（EBA）与“组合拳”（一）关于EBA上文谈到了架构演进的一个趋势，就是关注点从软件架构向企业架构的进化，这反映了技术在面对不断上升的业务复杂度时，对自身局限的认知。不深入了解业务和企业，就很难建立面向整个企业的系统规划，企业内部也就很难有效打通，事实上，比尔·盖茨先生1999年在《未来时速》中提出的为企业打造“数字神经”的想法，至今也还没能完全实现。“数字神经”的打造跟理清企业架构是分不开的，如同给一个城市设计管道系统一样，它与城市的结构是要匹配和共同演进的。而企业架构中非常重要、技术人员又很难处理的，正是业务架构。业务架构在Zachman手中萌生，到TOGAF时明确，尽管那个定义还是挺难理解的。TOGAF将企业架构（EA）和业务架构（BA）都推向了一个新高度，并且给出了包含业务架构在内的著名的“4A”结构，但是其实施难度一直饱受争议，由于周期通常较长，分析业务架构能够投入的业务人员就是有限甚至很难保证的，当然，这与企业自身的实施决心也有关。国外有些基于BA的成功案例，比如US Patent and Trademark Office（USPTO）于2013年启动了TMNG（TrademarkNext Generation）项目，按照BA方法梳理了企业层面的20多条价值链、19个1级能力、100余个2级能力，并按照能力复用等条件确定实施优先级，能力复用越多的，计划排期越靠前。TMNG项目持续5年，从第一年只能释放1组价值链环节，到第四年可以6组价值链环节同时实施，这一方面显示了对方法应用的熟练，另一方面也是来自于可复用能力的增加。国内，建设银行是贯彻业务架构方法的典范。由于长期受到“竖井式”开发的影响，该行于2011年痛下决心启动了“新一代核心业务系统”转型工程，以企业级业务架构方法驱动IT开发转型，进而推动企业转型。工程实施时间长达6年，通过业务模型方法构建了全行统一的业务架构，梳理了20余个业务领域、80余个业务应用、100余个业务组件、900余个活动、4500余个任务、20000余个数据实体，规划了全行100余个新老系统的SOA风格改造，将整个企业连接起来。此后，工行、中行也都在近两年构建了自己的企业级业务架构模型。综上，EBA其实对开发最大的指导作用在于它对业务的深刻理解、对企业整体性的解读与规划、对业务能力的聚类与组件的划分，从而使IT对业务的支持上升到合作、融合的高度而非原有的实现，它的作用其实更多还是在过程中，而非文字里。笔者基于原有的工作经验，将EBA设计方法进一步改造为通用方法论，以期能够为更多领域的设计人员提供借鉴。EBA方法这两年有复兴之势，一方面是有建行这样的大型实施案例，另一方面也有来自阿里巴巴这样的互联网头部企业对业务架构的重视。如果再说更深层次的原因，也许是现在又到了一个“转型”的时期，互联网企业这类跨界竞争者对原有行业的巨大冲击，使大家认识到，未来企业都将会带有较强的科技属性，信息化将进入它自身的高级阶段，并逐渐走向数字化阶段。这样的“转型”时期需要已经不仅是“一招鲜吃遍天”的爆款产品，更重要是大多数传统企业需要首先完成自身的“科技化”改造，需要首先实现企业内部技术基因的增强，实现业务与技术的深度融合，这种转型非常需要EBA的支撑。提高企业的整体性正是EBA方法的强项，正如笔者在《企业级业务架构设计：方法论与实践》一书中对EBA的定义：“以实现企业战略为目标，对企业能力进行整体规划并将其传导到IT实现端的结构化分析方法”。企业无分大小都有战略，都有架构，就算没有显性地表现出来，所以，各种规模的企业都可以尝试用EBA方法为自己诊脉，就算你没有最终将它应用于IT实现。笔者介绍的方法没有那么复杂，充分地认识自己不是坏事，正所谓“知己知彼，百战不殆”，毕竟，无论做不做系统开发，企业每发展到一定时间，总会积累些“管理债务”要去偿还，EBA本身也可以应用于“管理”上的重构。EBA的一般设计过程如图6所示：图7EBA的整体逻辑如图8所示，EBA强调的是“知行合一”，强调企业自己对方法论的驾驭和对架构师的培养，未来的企业管理必然包含架构管理，企业管理追求的“韧性”很可能将来自于架构的“弹性”和演化能力。（二）EBA与DDD方法之间的结合也是一个趋势，当然，结合是一件难度很高的事情，它的基本要求之一就是尝试结合者自己要对各个方法都有充分的了解和实践经验，并且能够让学习者可以掌握，因为对学习者而言，这意味着“1+1>2”的学习量。EBA方法在形成业务架构解决方案之后，本身对IT实现端采用的方法没有特殊的限制性要求，这也意味着进入IT实现端的需求分析阶段后，可以尝试采用DDD方法进行细化设计，因为二者都注重数据与行为的结合，EBA方法是通过流程模型与数据模型的结合进行表达的，DDD的实体表达方式则更为直接；二者都强调通用语言，只是范围上，EBA是跨领域的通用语言，而DDD是限界上下文内部的通用语言；二者也都希望实现业务和技术两端都能理解的解决方案，也都非常关注业务含义对模型设计的影响。但是二者也有区别，结合也有一些的困难要克服。一个比较直接的问题来自于数据模型，EBA方法注重对企业级数据模型的设计，企业级数据模型对数据治理有非常重要的作用，对大数据应用也有很直接的影响。数据模型通常的设计方式与DDD中对数据的处理有一些区别，二者在数据建模方面，对实体的定义有共同之处，比如应关注实体的业务含义，但是具体定义、实体大小的考量上，都会在实操层面有区别，而且，EBA方法比较提倡在企业层面的数据概念的抽象和统一，但是DDD是从领域出发考虑问题的，而且这个领域也不同于EBA中范围较大的领域概念，其限界上下文涵盖的范围可能很小，从而产生多个领域都有同名不同义的实体。比如，Vaughn Vernon在《领域驱动设计精粹》一书第二章介绍的“保单”的例子，就是在承保、审核、理赔三个限界上下文中分别定义了“保单”实体，每个实体都有重复的部分和差异的部分，这样做的原因则是认为整合会造成一个过于臃肿的“超负荷”的“保单”实体。这样的实体也许大家在设计过程中也曾经遇到过，就是一个数据实体包含了过多的属性，导致数据层面没有很好地分离“关注点”。Chris Richardson在《微服务架构设计模式》一书的第二章中也给出了一个通过DDD处理类似问题的例子，就是对“上帝类”的拆分，“上帝类”作为全局类，可以为多个不同领域的应用调用，因而也就设计了包含不同领域的状态和行为的复杂结构，比如书中提到的“Order（订单）”，下单、送餐、付款等多个领域都会触发订单状态的转换，如果将丰富的行为打包成一个中央Order数据库，会导致微服务设计方面出现“紧耦合”，微服务之间不够独立；如果只保留一个纯数据服务的Order Service，又会成为“贫血模型”。其解决之道同样也是在不同领域定义同名不同义的Order。这两个例子其实体现了与EBA很不同的处理方式，EBA希望实现企业级的数据模型定义，也即，在企业级范围内尽可能消除同名不同义的数据实体，所以，“保单”、“订单”在EBA中通常会处理为一个而非多个实体，那么解决实体过于庞大的问题，还是要依靠对数据实体的业务含义、业务能力的识别，因为按照领域的拆分本身也会存在弊端，就是企业级数据查询与应用的困难。
阿里云 Web 应用防火墙：全面保障网站的安全与可用性|学习笔记
开发者学堂课程【上云须知 - 全面了解阿里云能为你做什么：阿里云 Web 应用防火墙：全面保障网站的安全与可用性】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：/learning/course/381/detail/4779阿里云 Web 应用防火墙：全面保障网站的安全与可用性全面保障网站的安全与可用性互联网大数据时代，信息变得唾手可得。庞大的中国互联网正遭受层出不穷的安全威胁，黑客们的肆意攻击让网络安全攻防战必须时刻戒备。如何在这场看不见硝烟的战争中克敌制胜。现在阿里云云盾构筑了强大的 web 应用防火墙，汇集阿里巴巴 10 年攻防经验，云盾 WAF 在 web 应用防护，CC 攻击防护，业务风控 3 个维度，为您提供一套简单快速有效的安全防护解决方案，全面保障您的云业务系统安全，打造网络安全星纪元。每天互联网上都在爆发商业数据泄漏，恶意后门，挂马，网页篡改等事件。而这幕后的黑手就是 web 应用攻击，想要守住安全防线，抵御这只黑手，云盾 WAF为您轻松实现。它创新智能双引擎，利用正则威胁特征检测和 cico 语义智能分析引擎，应对外部攻击大大降低规则误报避免对正常业务的干扰，而安全背后来源于云盾 WAF 的情报和实时数据分析。面对每天爆发的零倍漏洞云盾 WAF 不断研究并推出最新虚拟补丁。沉淀 10 年攻防经验保 障 web 应用安全。基于阿里云的大数据计算能力，云盾 WAF每日内还可将数 10 亿海量用户业务中检测到的安全事件及疑似攻击进行数据模型分析，提炼，总结，应用，将威胁排除在您的视线之外。危险不仅仅于此，另一只黑手 CC 攻击同样不可小觑，它通过短时间内的密集轰炸，直接导致网站不可用。为了捉住这只黑手，云盾 WAF 开启阶梯式多层防护，让您掌握主动权。它能根据研究恶意请求的页面访问频率，URL 分布，请求来源 River 以及 user agent 等关键信息，快速分析出异常行为，并对可疑的访问请求来源方进行反向探测的人机识别。一旦掌握攻击特征，您就可一键设置精准的访问控制规则，针对恶意的 refer ，user agent， URL 地址请求等进行全面精准的有效拦截。由于攻击手段的迭代升级，CC 攻击更演变成了一只变异大军。此时把握安全威胁情报是关键。云盾 WAF 通过分析客户业务模型及安全事件数据，逐步完善并及时更新关于恶意 IP ，boat， 恶意特征，设备指纹及可信来源的信誉库，让您见招拆招。为业务筑起一道最新的防护城墙。风控是互联网永恒的话题，在线业务有多繁荣，衍生出的黑色产业就有多庞大。网站登录的暴力破解，黄牛党的恶意刷票，各种薅羊毛抢红包等，像洪水猛兽般发动了新一轮侵袭。结合多年阿里巴巴电商业务防护经验，云盾 WAF 祝您大破黑产魔，他首创了 web 应用防护结合业务风控的新一代应用安全解决方案，，通过网页中嵌入的人机识别脚本，对可以访问做进一步的滑块验证分辨人机行为不干扰网站的正常浏览。值得一提的是，您无需更改任何业务源码就会一键轻松拥有业务安全能力，提供最佳用户体验。让您的企业业务安全更简单，更智能。驱动 web 安全，开启专业防护，云盾 WAF 为您构筑新一代网络安全。
微服务场景下数据抽取与统计（1）
案例小故事某公司的技术架构体系目前还是以集群扩展体系为主，集群扩展体系架构如图9-1所示。在这种体系结构中，可以看到应用都是单块结构，但是单块结构的应用具有扩展性，通过部署在多个Tomcat上实现应用的集群，所有的应用都访问同一个数据库（这个库可以假设为Oracle数据库），数据库间采用DataGuard来实现主从同步，读库只具有读取功能，为后台数据统计功能提供数据查询和统计服务。目前业务请求的并发量每分钟有几十笔交易，看起来这套架构还是能够支撑目前的业务发展的。??突然有一天客户在做活动的时候，监控中心出现各种告警，在每分钟500TPS的时候很多请求超时，监控显示目前的服务器不能支撑这么大的并发量，于是快速增加服务器部署应用上线，发现根本没用，加了和没加一样，加几台都一样，运维和DBA发现此时的数据库压力非常大，好不容易熬过这段时间后，团队成员痛定思痛，一致认为目前的架构体系已经不能支持业务的发展，微服务开始快速推进。其中微服务的数据去中心化核心要点是：每个微服务有自己私有的数据库持久化业务数据。每个微服务只能访问自己的数据库，而不能访问其他服务的数据库。某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其他微服务的数据库，而是对微服务进行操作。数据的去中心化进一步降低了微服务之间的耦合度。问题随后就来了：（1）以前团队一共就10个人，只负责一二个项目，现在突然增加到平均每人维护二三个项目，上线还是采用由运维手工打war包，如果有修改的配置文件，则运维人员需要一台一台地进行修改，不仅容易上线出错，而且每次上线都会搞到半夜。（2）根据上面提到的数据去中心化原则，数据库拆分出来了，一个服务一个数据库实例，但是对后台统计系统来说就是“噩梦”，数据库拆分出来了，统计工作、报表工作该怎么办呢？这部分工作还做不做呢？有人说可以分开统计，一个库一个库进行统计，可是这样的工作量将是巨大的。（3）机房的双活问题，对于金融公司来说双活还是很关键的一项技术指标。应用双活其实比较容易实现，但对于数据库来说却是一个技术问题了，对于Oracle数据库来说，用Oracle官方提供的OGG（Oracle GoldenGate）进行数据同步，根据论坛上面的资料可以看出，OGG的“坑”非常多，而且也容易丢数据，更重要的是贵。采用Oracle的logminer进行同步，同步的数据不是实时的，会有一定延时。而且在定时读取方面还需要自己进行开发，采用Oracle的DataGuard也只能做主从同步，不能做主主双活。调研过后，最终还是决定自己独立开发。从单块系统到微服务是逐步演进的过程，如果前期没有调研，没有一个整体规划，后期在实现微服务的时候会发现需要做的事情只会越来越多，尤其是对于快速发展的创业型公司来说。针对以上问题，我们如何解决？上面说的第一个问题可以通过合理实施DevOps来解决，而第三个双活问题在本书相应章节中也有详细介绍，本章将给出合理方案深入讨论如何解决第二个问题，即如何在微服务场景下进行数据统计和抽取。在企业中，需要将不同服务所属的数据库数据抽取到数据仓库，以便能够对平台进行查询和统计，而优秀的数据仓库离不开良好的数据体系的支撑与维护，数据体系建设是一系列长期的、迭代的过程。什么是数据仓库第一次接触数据仓库的读者对这个概念会比较陌生，可能会有这样的疑问，什么是数据仓库？为什么要建立数据仓库呢？下面从数据仓库的定义、特点及数仓（数据仓库简称）与操作型数据库的区别三个方面了解数据仓库。1．数据仓库的定义最早数据仓库这个概念是由被称为“数据仓库之父”的Bill Inmon提出的，并且在其出版的Building the Data Warehouse一书中给出了数据仓库的详细定义。Inmon在Building the Data Warehouse中定义数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用来支持管理人员的决策。2．数据仓库的特点1）面向主题数据仓库采用面向主题的方式组织数据。数据仓库主要是为公司决策者提供数据依据，决策者更关注整体数据反映的情况。以面向主题的方式组织数据可以将各分散子应用或子系统的数据按照主题组织在一起，让决策者可以从更高层面分析数据，挖掘数据背后蕴藏的商业价值，指导决策者做出正确的判断。2）集成性数据仓库中集成了各分散数据源的数据。对多个来源、多种类型的数据进行统一加工、汇总、整理，去除数据中的“杂质”，规范字段格式，保证数据仓库中的数据具有全局一致性。3）相对稳定操作型数据库中的数据是实时更新的，数据仓库中的数据相对稳定，不会频繁地执行修改、删除操作。在数据仓库中以查询操作为主，数据经过加工进入数据仓库之后一般不会发生改变，会被长期保存或根据业务需求保存很长一段时间后被删除。4）反映历史变化数据仓库的主要任务是对大量历史数据进行统计分析，决策者根据历史数据分析结果预测未来发展趋势。
ES写入毛刺问题？从原理到调优
ES是一个非常完善的搜索引擎，可以用于业务搜索、数据分析，其周边生态产品也十分丰富； 正是由于ES的完善与通用性，用户使用ES的场景越来越多样化，通用的配置已经无法达到用户的稳定性需求，并且难以给出通用的最佳实践，需要专门的为某些场景进行调优。 例如，update频繁的场景下的性能调优。ES的使用场景1.在线搜索（垂直搜索+全文检索） 2.数据分析与日志 ES最初设计的就是一个搜索引擎，对全文检索更是“擅长”，准确且简单；后面由于性能的不断提升，集群规则的扩大，使得ES在OLAP（数据分析）场景也有很大的发挥空间； 无论是在线搜索还是数据分析，其使用场景依然是一个“上层”，并不作为一个最底层的数据源，数据链路依然是从DB数据源--->ES，这也是比较推荐的使用方式。ES不是数据库，没有事务、不保证任何情况下都不会丢失数据（数据先写lucene再写translog），以及近实时的特性，ES并不非常适合极其频繁的update场景。尽管如此，ES依然允许被这样使用，只是需要进行一些调优；问题是什么？有用户提出，update接口偶尔（一天3-4次）会出现请求耗时很高（1s+）的情况； 监控观察下来并没有在异常请求的时间点出现不正常的现象。 请求链路：用户service->gateway->ES集群实例 从日志看下来，时间主要用在从gateway发送请求到gateway得到ES的响应；由于是update请求，不会存在大量的网络IO，所以问题大概率出现在ES处理请求上。分析1.由于是频繁的update请求，很容易发现有大量的is_deleted文件，该现象主要影响查询性能，可通过forcemerge处理，实验下来对update毛刺没有任何影响，符合预期。（补充：segment过多也会影响查询性能，由于每个分片单独merge，出现的segment在某些分片上过多的情况也会造成查询的毛刺）2.用户根据我们提供的“最佳实践”文档，计算出了主副分片的设置，由于数据量不大，最终算出来是primary=1，replica=4，于是update场景下副本数过多，更容易造成长尾效应。 可以看到update的耗时等于node1上主分片update的耗时加上node2,node3,node4,node5中耗时的最大值。这样副本越多也就越容易出现长尾效应。 这里再提一点：wait_for_active_shards参数经常被误认为是控制写入请求同步分片的数量（认为在wait_for_active_shards=2的时候只需要等待1主+任意一个副本返回成功，即可响应给客户端）。实际上该参数表示需要写入成功wait_for_active_shards个分片才算写入成功。可以看到该参数默认是1，也就是说只要写入主分片成功就算此次请求成功，但是依然需要等待所有副本都响应了，才能返回客户端。 该参数是用来保证数据不丢失的，例如wait_for_active_shards=2，需要至少写入1主1副才算此次请求成功，这样一致性会更高，但相应的写入性能会更差。3.translog同步顺序写，在translog清空、翻滚的时候会有writeLock，也可能造成等待，导致update请求出现毛刺。可以将translog设置成异步，相应的异步丢数据的可能性就会增加。4.官方推荐使用SSD，且esrally测试结果普通SSD在大多场景下都表现比HDD好（成本问题没有考虑Nvme）。目前该用户集群使用HDD，调整成SSD。 5.之前有看到文章描述当使用BulkShardRequest时，ES的定期refresh的过程中可能出现write线程帮助refresh线程进行refresh的情况，从而导致write线程堵塞。该场景本文没有实际验证过。最后问题没有得到完美的解决，毛刺问题并没有完全得到避免，在此仅提供一些处理思路。 如有描述不准确的地方欢迎指正～
Wakawaka：华人企业用宜搭把数字化经验带进非洲
Wakawaka50-100人 / 物流 / 非洲-东非-坦桑尼亚 / OA管理系统“我们这些常年在异国他乡工作生活的华人，每次看到祖国的科技行业有优秀的产品研发出来，内心都会由衷地产生自豪感，自然也会毫不犹豫支持祖国的产品，所以当我第一次接触到钉钉宜搭时，就对它爱不释手。” ? ? ——Wakawaka总经理 宋涛Wakawaka成立于2018年，是一家服务非洲中资企业的物流公司，坐落于坦桑尼亚达累斯萨拉姆港口，经营范围包括清关、运输、保险、项目物流承包、海运等业务。在中国“一带一路”合作倡议的大背景下，非洲东南部正在高速发展，这些发展少不了物流运输行业的支持。Wakawaka凭借专业的团队、丰富的海外物流经验迅速成长起来。随着公司规模不断扩大，已有的信息化系统已经不足以承载业务扩张。Wakawaka数字化建设的四大难题人力成本过高：公司业务流程数据庞杂，已有的OA系统无法自动进行数据分析，需要人工导出后在Excel整理统计。每个月，相关工作人员要耗费大量时间在数据整理上。数据统计滞后：公司账务管理长期使用Excel统计，并每月汇总一次报表。决策者得到财务数据时往往会滞后，无法及时了解到每个项目的盈利状况、不能实时查看财务数据。数据呈现不清晰：公司的业务数据无法通过OA系统直接生成报表，都是经过人工统计后再通过Excel做成报表，导致决策者不能清晰直观地看出公司在运行的过程中产生的各类费用等信息，不能及时做出具体的决策指示。定制系统费时费力：公司一直在寻找适合自己的企业内部管理系统，曾找过海外软件公司做定制化开发，但实施成本高，开发周期长，沟通成本较大。也尝试过外采ERP软件，但使用过程中发现与实际需求不匹配而最终放弃。这让总经理宋涛常常感觉并不是软件在服务他们，而是他们在服务软件。2021年9月初，一次偶然的机会，宋涛联系到了钉钉宜搭合作伙伴上海致拓，在随后的沟通中，上海致拓帮助Wakawaka分析了企业内部存在的问题、详细指出问题发生的原因、并提出了解决方案。钉钉宜搭高度扩展的自定义页面、丰富的报表组件以及安全性，让宋涛意识到这正是公司需要的数字化工具，钉钉宜搭可以帮助Wakawaka从规范性和流程上进行数字化变革，最终达到降本增效的目的，提高企业在当地的竞争力。一个月上线OA管理系统，打通内部管理全流程借助钉钉宜搭，上海致拓仅用了1个月时间，就帮助Wakawaka建设好了一套OA管理系统，覆盖办公、贸易、财务、客户管理等场景。这套系统大幅提升了Wakawaka在内部的管理效率，智能化的数据分析也让管理者可以实时、清晰地掌握运营情况，并做出决策。因为Wakawaka在非洲聘用了很多来自当地的职员，为了让他们更加便捷的使用，这套系统还提供了全英文版本，也可实现中英双语一键切换。财务收支智能统计，大幅减少人力成本多币种费用结算：日常记录各类费用结算单，并同时支持人民币、美元、坦桑尼亚先令等其他多种货币类型。自动统计收支数据：各类费用支出与收入数据自动计算与显示，免去了手动收集与人工计算的麻烦，各类资产数据、账目数据可以实时汇总查看。 Wakawaka借助钉钉宜搭建设的这套OA管理系统，成功打通了财务、贸易、客户管理等相关业务，同时也把信息和数据的采集融入到员工日常工作中，并且数据加工全部实现自动化处理。通过可视化报表，可以实时监控业务与财务数据，方便快速调整运营与经营策略，为公司发展提供了可靠的支持，明显提升了公司的整体经营效率。在没有接触钉钉宜搭前，宋涛发现非洲的市场上没有一家公司的系统可以满足他的需求，而请海外软件公司定制化开发，高昂的实施成本也让他望而却步。使用钉钉宜搭后，系统仅用了1个月时间就完成搭建上线，不仅充分满足了公司的需求，从成本考虑也比预期降低了数十万，人力成本更是降低了70%。未来，Wakawaka还将把核心的货运业务搬运到钉钉宜搭上。“钉钉宜搭给我们带来了很多惊喜，我们不光要在非洲实现自己的理想，更要把中国先进的数字化转型经验带到这片土地上去。”宋涛说道。
总结与回顾（1）| 学习笔记
开发者学堂课程【机器学习概览及常见算法：总结与回顾（1）】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：/learning/course/529/detail/7118总结与回顾（1）?内容简介：1 学习内容2 学习目标3 思考与练习??1 学习内容（1）介绍算法的常见分类（2）介绍有监督学习算法,重点介绍 KNN、ID3（3）介绍无监督学习算法,重点介绍 Apriori、K-Means（4）介绍其他常见的算法??2 学习目标（1）了解无监督学习与有监督学习（2）掌握 KNN、ID3分类算法（3）掌握 Apriori、K-Means 算法（4）了解集成学习等其他算法??3 思考与练习01了解有监督学习和无监督学习的区别,分别描述几个相关的场景。02用自己掌握的编程语言，实现分类算法 K-NN 和聚类算法 K-Means03思考一下 KNN、K-Means 等算法的优缺点,制定一-些优化缺点的方案04找几个小的周知数据集,按照课程中介绍的算法逻辑,手工计算一下，评估一下结果。包括关联规则、ID3 决策树等。05 ID3 算法无法处理连续特征,想一些解决办法,自己动手试一下。了解一 下 C4.5 ?算法的工作原理。
有监督学习算法（下）| 学习笔记
开发者学堂课程【机器学习概览及常见算法：有监督学习算法（下）】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：/learning/course/529/detail/7122有监督学习算法（下）?内容简介：?1 决策树:构建流程2 熟悉数据。明确目标3 信息熵4 信息增益和特征选择5 构建决策树6 第一级特征选择7 ID3系列算法8 CART9 其他常见有监督学习算法??1 决策树:构建流程（1）准备工作明确自变量和因变量确定信息度量的方式确定终止条件（2）选择特征得到当前待处理子集计算所有特征信息度量得到当前最佳分类特征（3）创建分支根据选中特征将当前记录分成不同分支，分支个数取决于算法（4）是否终止判断是否满足终止条件满足则退出循环不满足则继续递归调用（5）结果生成判断是否需要剪枝需要则进行适当修剪不需要则为最终结果观察数据,明确自变量和因变量??2 熟悉数据。明确目标■自变量■因变量明确信息度量方式:信息增益■熵■基尼系数明确分支终止条件■纯度■记录条数■循环次数根据电脑购买记录,对购买者建模。该模型可以基于客户的一些信息预测他是否会购买电脑。??3 信息熵■信息论里的概念,香农提出■描述混乱程度的度量■取值范围 0~1 ,值越大,越混乱■计算公式:有一堆苹果和梨共100个,随机拿出一个,拿出的是哪种?■50个苹果+ 50个梨子■0个苹果+ 100个梨子■80个苹果+ 20个梨子E1=-50/100*log(50/100,2) - 50/100*log(50/100,2) = 1E2=-100/100*log(100/100,2)=0E3= -20/100*log(20/100,2) - 80/100*log(80/100,2) = 0.722??4 信息增益和特征选择信息增益■信息是确定性的增加■从一个状态到另一一个状态信息的变化■信息增益越大,对确定性贡献越大搜集了几种植物果实的颜色和味道,根据这两个信息确定是否为水果?不考虑任何特征,直接去估计结果:其中,两个是水果,两个不是水果,概率均为2/4 :E= -2/4*log(2/4,2) - 2/4*log(2/4,2)=1考虑以颜色为参考信息,判断是否为水果:其中,红色的有3个,2个是水果,一一个不是,绿色的都不是,概率分别为: 2/3,1/3以及1, 0E=3/4*(-2/3*log(2/3,2) - 1/3*log(1/3,2)) + 1/4*(-1*log(1,2)) = 0.689考虑以味道为参考信息,判断是否为水果:其中,甜味的2个,全是水果,不甜的2个,全不是水果,概率分别为:1,0以及0,1E=2/4*(- 2/2*log(2/2,2)) + 2/4*(- 2/2*log(2/2,2)) = 0信息增益:颜色: 1-0.689=0.311味道: 1-0=1??5 构建决策树6 第一级特征选择计算整体的熵:购买: 9例，未购买: 5例计算年龄的熵计算收入的熵计算单身的熵计算信用的熵??7 ID3 系列算法ID3 ( Iterative Dichotomiser 3，迭代树三代)■核心是信息熵,根据信息增益决定树的节点■存在以下问题:V 信息度量不合理:倾向于选择取值多的字段V 输入类型单一:离散型V 不做剪枝，容易过拟合C4.5 :和ID3相比的改进:V 用信息增益率代替信息增益V 能对连续属性进行离散化，对不完整数据进行处理V 进行剪枝C50 : C4.5相比的改进:V 使用了 boostingv 前修剪、后修剪8 CARTCART ( Classification and Regression Tree )■核心是基尼系数( Gini )■分类是二叉树■支持连续值和离散值■后剪枝进行修剪■支持回归,可以预测连续值9 其他常见有监督学习算法分类算法:■KNN ( K最近邻，K-Nearest Neighbour)■NB (朴素贝叶斯 ，Naive Bayes )■DT (决策树, Decision Tree ) : C45、CART■SVM (支持向量机, Support Vector Machine )回归预测:■线性回归( Linear Regression )■逻辑回归( Logistic Regression )■岭回归( Ridge Regression )■拉索回归( LASSO Regression )
有监督学习算法（上）| 学习笔记
开发者学堂课程【机器学习概览及常见算法：有监督学习算法（上）】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：/learning/course/529/detail/7121有监督学习算法（上）?内容简介：1、 什么是有监督学习算法2 、分类: Classification3 、回归: Regression4 、分类算法5 、KNN6 、实现步骤图示7 、实现伪码8、 KNN优缺点??1 什么是有监督学习算法有监督学习( Supervised learning ) :利用一-组已知类别的样本来训练模型，使其达到性能要求。特点为输入数据(训练数据)均有一个明确的标识或结果(标签)。即我们提供样例"教”计算机如何学习。??2 分类: Classification分类:就是通过已有数据集(训练集)的学习,得到一个目标函数f (模型) , 把每个属性集x映射到目标属性y (类) ,且y必须是离散的(若y为连续的，则属于回归算法)。通过对已知类别训练集的分析,从中发现分类规则,以此预测新数据的类别。已有部分用户是否会购买电脑的记录，据此去建模,来预测某个新用户是否购买。即分成两类:购买和不购买??3 回归: Regression采集了一些父子的身,对这些数据进行建模，然后使用模型，根据输入的新的父亲的身高去预测其子身高的取值。?拟合线性方程: Y =a*X + b最小二乘法,带入样本数据求解:解: a=0.5119 b= 86.3246模型结果: Y = 0.5119*X + 86.3246 我身高177.5 cm，则我的孩子身高:Y = 0.5119*177.5 + 86.3246= 177.18???4 分类算法分类算法通过对已知类别训练集的分析,从中发现分类规则,以此预测新数据的类别。分类算法的应用非常广泛,银行风险评估、客户类别分类、文本检索和搜索引擎分类、安全领域中的入侵检测以及软件项目中的应用等。按原理分类■基于统计的:如贝叶斯分类■基于规则的:如决策树算法■基于神经网络的:神经网络算法■基于距离的: KNN ( K最近邻)常用评估指标:■精确率:预测结果与实际结果的比例■召回率:预测结果中某类结果的正确覆盖率■F1-Score :统计量,综合评估分类模型,取值0-1之间??5 KNNKNN : k-Nearest Neighbour ,分类算法中最简单的算法之一，其核心思想是如果离某一个样本最近的 k 个本中的大多数属于某一个类别,则该样本也属于这个类别，并具有这个类别上样本的特性。KNN 不但可以预测分类，还可以做回归分析(预测具体的值)。有N个已知分类结果的样本点,对新记录 r 使用 KNN 将其分类的步骤:Step 1:确定 k 值，确定计算距离的公式,比如欧氏距离Step2:计算 r 和其他样本点之间的距离 di;r,其中i∈(1,N)Step 3 :得到目前和 r 最接近的 k 个样本,作为 KNN 距的训练样本Step4 :将 k 个样本中最多归属类别的分类标签赋予新记录 r ,分类结束??6 实现步骤图示第一步，确定 k 的取值,确定距离公式?K 的取值不宜过大,使用交叉验证确定,本例中选择 k=10第二步,计算 r 和所有样本点的距离第三步,圈定符合条件的 k 条记录?将距离升序排序,得到 topk 小的值,选入 KNN 样本??7 实现伪码repeat计算已知类别数据集中的点与当前之间的距离按照距离递增次序排序until 样本点遍历完成返回前k个样本点统计 k 个样本点中出现频率最高的类别标签??8 KNN优缺点优点原理简单，容易理解,容易实现重新训练代价较低时间、空间复杂度取决于训练集(一般不算太大)缺点:KNN 属于 lazy-learning 算法,得到结果的及时性差k 值对结果影响大(试想一下 k=1 和 k=N 的极端情况)不同类记录相差较大时容易误判样本点较多时,计算量较大相对于决策树，结果可解释性不强??
无监督学习算法（下）| 学习笔记
开发者学堂课程【机器学习概览及常见算法：无监督学习算法（下）】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：/learning/course/529/detail/7124无监督学习算法（下）?内容简介：1 关联规则: Association Rule?2 常见算法??1 关联规则: Association Rule关联规则是反映事物与事物间相互的依存关系和关联性。如果两个或多个事物间存在一定的关联关系,则其中一个事物能够通过其他事物预测到。最常见的场景就是购物篮分析( Market Basket)。通过分析顾客购物篮中的不同商品之间的关系,来分析顾客的购买习惯。经典案例就是啤酒与尿布。根据某超市的购物篮信息，分析顾客的购物习惯，制定货物摆放或者捆绑销售策略。(Apriori)?首先确定最小支持度: 50% ,最小置信度: 50%确定1 -频繁项集????{A}:50%,{B}:75%,{C} 75%,{E}:75%确定2-频繁项集?????{A,C}:50%,{B,C}:50%,{B,E} 75%,{C,E}:50%确定3-频繁项集????{B,C, E}:50% 确定关联规则:????非空子集: {B},{C}{E},{B,C},{B,E},{C,E}2 常见算法聚类算法:■ K 均值( K-Means )■DBScan■最大期望(EM:Expectation Maximization )■降维: PCA(主成分分析)、PLS (偏最小二乘回归)、MDS (多维尺度分析)............关联规则:■Apriori■Eclat■......
