业务场景各有不同,分享内容时不要太具体到哪个业务场景,应该找到变化中不变的部分。万变不离其宗,先把本质学好。
单体应用业务复杂后,应用无法扩展,可靠性低。而且无法针对热点模块单独处理。整体资源利用率低。
微服务是SOA的一种实践。
围绕业务功能建设的,服务关注单一业务,由于服务间通信频繁,需要采用轻量级的通信。单独部署维护,可使用不同的编程语言和存储技术。服务组件化后,方便复用,系统架构清晰,高效开发。
Fred Brooks 在30年前写道,“there are no silver bullets”
运维难,基础设施建设难,复杂度高。
测试难,服务上游多,测试不清楚是缺陷还是上游服务的问题。对应的是沟通协调成本增加,测试环境服务此时是否能更新,更新后需要通知他人
微服务应用是分布式系统,由此会带来固有的复杂性。开发者不得不使用 RPC 或者消息传递,来实现进程间通信;此外,必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。
分区的数据库架构,同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易,因为只有一个数据库。在微服务架构应用中,需要更新不同服务所使用的不同的数据库,从而对开发者提出了更高的要求和挑战。
服务模块间的依赖,应用的升级有可能会波及多个服务模块的修改。
以前是单体应用,业务操作大部分是进程内完成。微服务后,一个业务操作涉及到多个服务之间通信,通过rpc完成。一个请求到了应用后,应用和下游的服务进行网络交互会放大100倍。也就是微服务会给网络带来压力。不过部分情况可能是代码层面的问题。以前是循环查库,瓶颈大部分在DB。现在循环rpc,网络问题被放大。解决办法:batch化,提供粗粒度的接口。
单体应用中,复杂的业务场景下,涉及到多个业务流程。除非某个流程特别耗时,一般采用串行执行。因为即使可以使用线程池来进行并行处理,但这个优化带来的收益太小,不如想想DB瓶颈咋解决。但在微服务中,每个业务流程可能设计到需要和其他服务通信,这是比较耗时的,所以可以结合实际场景,并行执行。
服务之间的通信没有进程内通信可靠,失败后如何处理,进而暴露出复杂的一致性问题。
DB由一个演进为多个,虽然压力被分担,但也带来了棘手的问题,例如分布式事务。
需要部署的应用数量直线上升,日志、监控都需要改造升级,应用管理难度更大。
以前应用有问题,ssh连上去看看日志,arthas监控下,或者本地启应用复现问题调试。上了微服务后,前端反应一个问题,是哪个后端服务导致的呢?应该看哪个服务的日志?排查起来要困难许多。
微服务之前,为了复用代码,在垂直应用中,抽取了部分代码,封装为业务组件,通过依赖库的形式提供给上层应用使用。缺点是业务组件更新,需要所有使用该业务组件的上层应用重新构建。在复杂系统中,这是个很耗时的事情,之前做的垂直架构系统,构建一个上层应用需要好几分钟。
微服务化后,将业务组件封装为业务中台服务,场景层通过rpc调用即可。这时业务组件是可以单独维护的,只要不涉及协议层的变更。另外,我们还会封装一部分基础、业务无关、通用、未来很少变更(不涉及业务)的代码为基础组件库。
本质上等同于:多个微服务组合完成了一个完整的用户场景(usecase)
按业务能力组织服务的意思是服务提供的能力和业务功能对应,比如:订单服务和数据访问服务,前者反应了真实的订单相关业务,后者是一种技术抽象服务不反应真实的业务。所以按微服务架构理念来划分服务时,是不应该存在数据访问服务这样一个服务的。
事实上传统应用设计架构的分层结构正反映了不同角色的沟通结构。所以若要按微服务的方式来构建应用,也需要对应调整团队的组织架构。每个服务背后的小团队的组织是跨功能的,包含实现业务所需的全面的技能。
B站的模式:大前端(移动/Web) =》 网关接入 =》业务服务 =》平台服务 =》基础设施(PaaS/Saas) 开发团队对软件在生产环境的运行负全部责任!
设计系统的架构受制于产生这些设计的组织的沟通结构。
即系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。
康威定律源于模块的设计者需要互相之间频繁沟通。而跨部门交流比较难。[2]
埃里克·雷蒙在《新黑客词典》中,称康威定律指出了软件架构与软件团队架构的等价(congruent)。
如果团队、部门、子部门等的组织结构没有紧密反映产品的必要组成或产品组成的关系,那么项目将会遇到麻烦。因此,应该确保组织结构兼容于产品架构。
每个服务面临的业务场景不同,可以针对性的选择合适的技术解决方案。但也需要避免过度多样化,结合团队实际情况来选择取舍,要是每个服务都用不同的语言的技术栈来实现,想想维护成本真够高的。
每个服务独占一个db、cache,避免db发生故障影响全部服务,例如一条慢sql。体现微服务隔离性,提高整体可靠性。
流量热点,去全局热点
尽量收敛
无自动化不微服务,自动化包括测试和部署。单一进程的传统应用被拆分为一系列的多进程服务后,意味着开发、调试、测试、监控和部署的复杂度都会相应增大,必须要有合适的自动化基础设施来支持微服务架构模式,否则开发、运维成本将大大增加。
Version:0.9 StartHTML:0000000105 EndHTML:0000005226 StartFragment:0000000141 EndFragment:0000005186
Be conservative in what you send, be liberal in what you accept.