9 基于容器的微服务架构技术选型与设计.docxVIP

基于容器的微服务架构技术选型与设计 作为金融企业，国投瑞银基金多年以来 IT 工作次要还是以运维为主，次要业务系统基本接受外购模式，但随着业务的不断进展，业务部门共性化需求越积越多，外购与外包已经不能很好满足业务员部门的需要了。2021 年底公司着手开发团队的组建工作，同时对公司的业务开发平台进行架构选型与设计，以求统一开发平台，提升研发效率，从而加快业务部门的业务需求处理效率。 下面我们将就这两年在平台架构选型、平台架构设计、平台及相关子系统的逐渐完善背后的一些阅历进行共享。 适用对象 该架构全部基于开源平台，经过三年多的生产上线实践，平台运转平稳，可扩展性强，可用性高，可以很好满足公司对于金融业务不断进展的需要，这对类似的中小型企业的业务架构选型也具有肯定的参考意义。 注：UFOS：国投瑞银基金运营系统 架构设计与选型 架构设计考量因素 在初期平台架构设计与选型时，我们依据现有业务系统的需求，梳理出了技术架构选型需要考量关键因素： 架构平台的前瞻性或先进性，符合当前潮流与将来进展趋势，有较好的生态链和较强的生命力，不能由于平台架构选型不当，导致将来平台重新架构，形成大量的迁移和重构工作，需保障平台架构能在一段时间内保持技术领先。 这里有两点留意，一是对技术成熟度的考量，能否接受有风险的前沿技术以及拥抱这种技术带来的风险，这一点类似于金融投资中收益与风险的关系，我们需要在系统的先进性与系统的稳定性之间进行平衡；二是接受前沿技术可能会面对更多的困难，如国内可能缺乏相关材料，或难以找到可以参考的成功案例，很多时候只能通过官方和论坛猎取相关技术信息，会对架构按时交付带来风险。 平台的可扩展性 能满足基金行业业务不断的进展与创新的需求，尽量能做到平台的横向平滑扩展，满足以上特性其实就打算了架构的分布式特性，当然我们更期望它是云原生的架构 系统的牢靠性和可用性 作为金融业务系统平台，需保证业务系统连续不间断运转，保证平台的高可用。接受集群或平台自动恢复功能，确保平台局部出错也不影响系统全体的运转；这里有两个层面，一是业务系统中的功能组件能相互隔离，其中一个组件的不行用不能影响到系统的其他部分；二是平台基础系统接受集群架构，有自动恢复功能，确保即便系统中有节点出错，也可在很短时间内完成出错节点中服务的切换与恢复 开销 不同的架构 / 技术选择有着不同的开发成本，包括技术框架，平台的学习成本，我们期望平台能支持异构的技术，使得开发人员可以接受比较适合的技术栈来快速实现业务功能的开发 开发运维一体化思想（ DevOps ），在设计时考虑运维，尽量削减后期运维操作的简单度，减轻后期业务系统运维的负担。 让开发人员更多专注在业务功能需求开发，其它非功能需求如负载均衡、高可用等尽量由平台供应，做到对开发人员透亮?????，以提升开发效率。 当公司规模不大，实力不足以本人实现部分或全部架构，选择现成的“轮子”来组装本人的架构就成了一种自然的选择。在选择上可能会更多考虑如何使用更“标准”的“轮子”来满足本人业务的需求，以便于今后业务的升级和扩展。 要实现上述平台的扩展性和高可用性，一般都离不开分布式架构，而分布式架构一般离不开服务来承载 。 基于服务架构演进 基于服务的架构设计早已有之，比如基于 RPC 的服务调用，最早可追溯到 CORBA，以及现在还有很多金融公司在买卖系统中使用的 BEA 晚期的框架 Tuxedo（次要编程言语为 C/C++）。后来者有 Facebook 的 Thrift，Google Protocolbuf 框架 /grpc，阿里的 Dubbo 框架等等。这些框架支持消息的二进制编码（序列化与反序列化），效率高，因而成了对网络传输，并发处理要求高的应用如 App 应用，玩耍，买卖软件等的首选。 后来随着 HTTP 协议的广泛应用，进展衍生出面对服务的架构（SOA）的架构设计，该架构一般都应用在比较简单，大型项目中，为了异构系统中的功能复用，或系统功能的考量将功能模块独立出来成为服务，服务可以分布式部署，服务之间通过标准的软件接口方式在网络中相互调用；为了统一服务调用标准，SOA 往往还引入了数据总线概念，服务可以通过数据总线进行服务注册，服务的查找与调度。 SOA 架构中的服务之间是松耦合的，服务的颗粒度相对比较粗，而近些年消灭的微服务，则可以看作是对 SOA 服务的一种精简，细化，或者说是 SOA 服务的轻量版。 微服务 在谈及微服务的时候，大都会对应到单体应用，以示鲜亮对比；单体应用其实就是一个服务中包含了太多种功能的应用，它跟面对对象的设计里的单体类（包含太多功能实现的类）的提法颇有些类似，英文单词中有一个专出名词 monolithic 来描述二者： 假如你再认真对比微服务和类，你会发觉两者有诸多相像之处，比如微服务和类在