Dubbo开发者日活动成都站微服务领域的一些心得。2012年，JamesLewis在波兰举行的第33届克拉科夫会议上分享了一个名为“微服务-Java，Unix之道”的案例。在本次分享中，JamesLewis分享了他在2011年参与的一个项目中采用的一系列实践，用UNIX的哲学重新审视企业级Java应用，并将其中一些称为“微服务”。总结了五大特点：Smallwithsingleresponsibility——“Smalltoonlyhaveasingleprinciple”ContainerlessandinstalledaswellbehavedUnixservices——“De-containerizedandinstalledasaUnixService”位于不同的VCS根目录——”分布在不同的版本控制代码库中“自动配置——”自动初始化“状态感知和自动缩放——”关注状态和自动扩展“2014MartinFowler试图概括JamesLewis的微服务定义，使其不仅可以是用于不同的语言架构和技术栈上。也可以兼顾敏捷、DevOps等其他技术，成为架构上“最佳实践”的集合。提出9大特点：通过服务组件化，围绕业务能力组织，产品而非项目，智能端点和哑管道，去中心化治理，去中心化数据管理，基础设施SamNewman2016中的自动化、故障设计和进化设计《Building Microservice》4个特征和7个原则。4大特点：可独立部署。通过网络进行通信。对消费者透明。保持尽可能低的耦合并使其自治。7条原则：围绕业务概念建模、拥抱自动化文化、隐藏内部实施细节、使一切去中心化、可独立部署、隔离故障并具有高度可观察性。这里需要澄清一点。在工作过程中，偶尔会听到一些同学说，我用过Dubbo、spring-boot、Spring-Cloud，我开发的系统是微服务。在我个人看来，微服务是一种架构风格或架构原则，与实现系统的框架无关。比如：满足以上特点和原则的系统，使用WebService进行通信，不就是微服务吗？当然在实际实现过程中应该选择轻量级的通信框架。微服务从2014年开始在国内普及，这五年来，有很多文章介绍微服务的优势，比如逻辑清晰、部署简单、可扩展、组合灵活、技术采购容易、故障隔离等，我赢了详细展开到现在。综合微服务带来的挑战1.可用性降低综合微服务后，原来的单体应用可能会拆分成多个独立的进程。大多数公司为了避免进程之间的资源争用，都是独立部署的，即在单个虚拟机中只部署一个jvm进程。于是，引入了更多的服务器、网络设备、安全设备，这些硬件设备的可靠性会影响业务的连续性。对于服务之间的跨进程通信，需要选择通信协议和序列化框架，额外引入的代码可靠性也会影响整体的可用性。因此，微服务的设计需要针对故障进行设计，设计时要考虑重试、幂等、故障隔离、熔断、降级等。2.事务复杂度微服务拆分后，虽然按照领域模型做了解耦，但是必然会导致分布式事务问题。目前社区已经有一些分布式事务的解决方案和开源框架。解决方案包括基于消息队列的最终一致性、TCC分布式事务框架、自动化分布式事务框架，如Seata等，但分布式事务的处理对于开发者来说设计难度较大。要求比较高，使用成本也比较高。拆分时，建议尽量避免分布式事务，引入分布式事务框架来评估成本和收益。3.运维复杂度当单个应用被拆分成多个微服务时，应用的数量会大幅增加。如果没有可靠稳定的运维平台或者资源编排平台（比如k8s），全面的微服务对于运维来说将是一场灾难。工作量的大幅增加将直接影响系统稳定性和业务连续性。4.调试优化复杂度应用拆分后，业务调用关系变得更加复杂，整个调用链变长。如果没有合适的调用链跟踪平台，很难定位整个系统的性能瓶颈，调优成本非常高。还有一个问题是，当生产环境的业务数据出现异常时，由于调用链太长，如果没有标准化的Request和Response日志，很容易造成各个服务相互指责，难以定位问题。全面微服务后，由于服务节点数量众多，调优和排查问题更加依赖日志平台，高性能的日志平台也会提升效率。5、测试难度单体应用情况下，调用链路较短，一般做黑盒测试，测试人员不需要了解复杂的业务实现。微服务改造后，单个业务可能由多个服务组合编排。如果继续做黑盒测试，就意味着要等所有的业务都开发完了再进行，测试周期长，定位难。做边界测试需要覆盖更多的测试用例，测试的整体成本变高。在这种情况下，单元测试和单系统测试的重要性就凸显出来了。如果你需要做单系统测试，你可能需要模拟被调用的服务。通讯协议用http就可以了。社区中有许多可用的开源框架。如果是RPC框架，意味着需要准备一个好的mock测试系统来支持单机测试。6、领域建模中使用聚合查询时，一般是按照用户的角度进行划分，运营需求和用户需求本来就不在同一个维度。例如：按照用户维度域建模，会划分用户服务和订单服务，用户和订单数据存储在不同的数据库中。假设有查询某年龄段用户订单的操作需求。当用户量达到千万级别的时候，这个需求对于微服务系统来说就是一场灾难。需要一个强大的大数据平台，按照业务维度聚合数据，以满足运营查询需求和报表功能。微服务拆分原则在微服务拆分原则中，需要特别提到康威定律。康威定律简单的说就是系统设计（产品结构）等同于组织形式，每个设计系统的组织等同于组织之间的沟通结构。如果单一服务由不同的组织管理，则需求无法统一，存在牵扯多方、干扰需求的风险。可扩展性需求，同一个流程内的不同业务功能，有时业务量会有很大的差异，具体需要的流程数量也会相差很大。这样的模块锁在同一个进程中，必然会造成资源浪费。部署频率，同一个交付物中的不同组件有不同的发射频率，这会大大增加发射过程的频率，造成人员的大量浪费。修改的依赖性，如果同一个可交付成果中的不同组件经常被同步修改，这可能表明如果发生拆分，这两个模块应该“在一起”。领域建模，针对业务领域，引入限界上下文（BoundedContext）和上下文映射（ContextMap），合理分解业务领域，识别核心领域（CoreDomain）和子领域（SubDomain），确定边界域和它们之间的关系。根据核心域和子域划分微服务边界。对于单个应用来说，拆分的过程应该是循序渐进的，一步一步的拆分，从简单到复杂，从粗到细，这是一个循序渐进的过程。比如先把边界明显的业务拆分成独立的服务，边界不明确的先混合，等业务需求逐渐清晰后再拆分。拆分时，先拆分成若干个比较粗粒度的服务，根据业务需要，逐步将比较稳定、可以落户的粗粒度服务拆分成独立的服务。在这个过程中，原有的单体应用也可以承担部分兼容能力，在改造完成之前，不会对外部系统造成太大的影响。微服务的拆分与业务需求强相关。如果业务需求变化不大，比较稳定，处理的请求并发数不高，单体应用的稳定性和可维护性更好，更适用。总结微服务不是灵丹妙药，而是一种用于应对海量用户、复杂业务和需求频繁变化的架构风格。引用一句话“好的架构是演化出来的，而不是设计出来的”。引入任何一种架构都会有利有弊，如何平衡才是最重要的。四川新网银行，全国三大互联网银行之一，于2016年12月28日正式开业。新网银行注册资本30亿元，由新希望集团、小米、红旗连锁等股东共同发起设立。是中国银监会批准的第七家民营银行、四川省第一家民营银行、第二家获得国家高新技术企业认定的全国性银行。新网银行坚持“移动互联网、普惠替代”的差异化定位和“数字普惠、开放连接”的特色经营，努力成为数字科技普惠银行，依托领先的金融科技能力、稳健先进的大数据风控科技高效的互联网开放平台运营模式，服务小微群体，支持实体经济，践行普惠金融。截至目前，已服务超过2900万用户，累计发放贷款超过9000万笔。作者信息：谢彦泽，目前就职于新网银行，负责技术中心建设及核心系统技术架构设计。关注云原生领域，探索金融行业实践思路。原文链接本文为云栖社区原创内容，未经允许不得转载。
