有关微服务的毕业论文

显然，随着系统复杂度的提升，以及对系统扩展性的要求越来越高，微服务化是一个很好的方向，但除此之外，微服务还会给我们带来哪些好处？ 独立，独立，还是独立 我们说微服务打响的是各自的独立战争，所以，每一个微服务都是一个小王国，这些微服务跳出了“大一统”（Monolith）王国的统治，开始从各个层面打造自己的独立能力，从而保障自己的小王国可以持续稳固的运转。 首先，在开发层面，每个微服务基本上都是各自独立的项目（project），而对应各自独立项目的研发团队基本上也是独立对应，这样的结构保证了微服务的并行研发，并且各自快速迭代，不会因为所有研发都投入一个近乎单点的项目，从而造成开发阶段的瓶颈。开发阶段的独立，保证了微服务的研发可以高效进行。 服务开发期间的形态，跟服务交付期间的形态原则上是不需要完全高度统一的，即使我们在开发的时候都是各自进行，但交付的时候还是可以一起交付，不过这不是微服务的做法。 在微服务治理体系下，各个微服务交付期间也是各自独立交付的，从而使得每个微服务从开发到交付整条链路上都是独立进行，这大大加快了微服务的迭代和交付效率。 服务交付之后需要部署运行，对微服务来说，它们运行期间也是各自独立的。 微服务独立运行可以带来两个比较明显的好处，第一个就是可扩展性。我们可以快速地添加服务集群的实例，提升整个微服务集群的服务能力，而在传统 Monolith 模式下，为了能够提升服务能力，很多时候必须强化和扩展单一结点的服务能力来达成。如果单结点服务能力已经扩展到了极限，再寻求扩展的话，就得从软件到硬件整体进行重构。 软件行业有句话：“Threads don't scale，Processes do！”，很明确地道出了原来 Monolith 服务与微服务在扩展（Scale）层面的差异。 对于Java开发者来说，早些年（当然现在也依然存在），我们遵循 Java EE 规范开发的 Web 应用，都需要以 WAR 包的形式部署到 TOMCAT、Jetty、RESIN 等 Web 容器中运行，即使每个 WAR 包提供的都是独立的微服务，但因为它们都是统一部署运行在一个 Web 容器中，所以扩展能力受限于 Web 容器作为一个进程（process）的现状。 无论如何调整 Web 容器内部实现的线程（thread）设置，还是会受限于 Web 容器整体的扩展能力。所以，现在很多情况下，大家都是一个 TOMCAT 只部署一个 WAR，然后通过复制和扩展多个 TOMCAT 实例来扩展整个应用服务集群。 当然，说到在 TOMCAT 实例中只部署一个 WAR 包这样的做法，实际上不单单只是因为扩展的因素，还涉及微服务运行期间给我们带来的第二个好处，即隔离性。 隔离性实际上是可扩展性的基础，当我们将每个微服务都隔离为独立的运行单元之后，任何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，而不会大面积地波及整个服务运行体系。 在架构设计上有一种实践模式，即隔板模式（Bulkhead Pattern），这种架构设计模式的首要目的就是为了隔离系统中的各个功能单元和实体，使得系统不会因为一个单元或者服务的失败而导致整体失败。 这种思路在造船行业、兵工行业都有类似的应用场景。现在任何大型船舶在设计上都会有隔舱，目的就是即使有少量进水，也可以只将进水部位隔离在小范围，不会扩散而导致船舶大面积进水，从而沉没。当年泰坦尼克号虽然沉了，但不意味着他们没有做隔舱设计，只能说，伤害度已经远远超出隔舱可以提供的基础保障范围。 在坦克的设计上，现在一般也会将弹药舱和乘员舱隔离，从而可以保障当坦克受创之后，将伤害尽量限定在指定区域，尽量减少对车乘成员的伤害。 前面我们提到，现在大家基本上弱化了 Java EE 的 Web 容器早期采用的“一个 Web 容器部署多个 WAR 包”的做法，转而使用“一个 Web 容器只部署一个 WAR 包”的做法，这实际上正是综合考虑了 Web 容器的设计和实现现状与真实需求之后做出的合理实践选择。 这些 Web 容器内部大多通过类加载器（Classloader）以及线程来实现一定程度上的依赖和功能隔离，但这些机制从基因上决定了这些做法不是最好的隔离手段。而进程（Process）拥有天然的隔离特性，所以，一个 WAR 包只部署运行在一个 Web 容器进程中才是最好的隔离方式。 现在回想一下，好像自从各个微服务打响独立战争并且独立之后，无论从哪个层面来看，各自“活”得都挺好。 多语言生态 微服务独立之后，给了对应的团队和组织快速迭代和交付的能力，同时，也给团队和组织带来了更多的灵活性，实际上，对应交付不同微服务的团队或者组织来说，现在可以基于不同的计算机语言生态构建这些微服务，如图 1 所示。 微服务的提供者既可以使用 Java 或者 Go 等静态语言完成微服务的开发和交付，也可以使用Python或者 Ruby 等动态语言完成微服务的开发和交付，对于团队内部拥有繁荣且有差异的语言文化来说，多语言生态下的微服务开发和交付将可以最大化的发挥团队和组织内部各成员的优势。 当然，对于多语言生态下的微服务研发来说，有一点需要注意：为了让服务的访问者可以用统一的接口访问所有这些用不同语言开发和交互的微服务，应该尽量统一微服务的服务接口和协议。 在微服务的生态下，互通性应该是需要重点关注的因素，没有互通，不但服务的访问者和用户无法很好地使用这些微服务，微服务和微服务之间也无法相互信赖和互助，这将大大损耗微服务研发体系带来的诸多好处，而多语言生态也会变成一种障碍和负累，而不是益处。 记得时任黑猫宅急便社长的小仓昌男在其所著的《黑猫宅急便的经营学》中提到一个故事，日本国铁曾经采用不同于国际标准的集装箱和铁路规格，然后发现货物的运输效率很低，经过考察发现，原来是货物从国际标准集装箱卸载之后，在通过日本国铁运输之前，需要先拆箱，重新装入日本国铁规格的集装箱，然后装载到日本国铁上进行运输。 但是，如果日本国铁采用国际标准的集装箱规格，那么货物集装箱从远洋轮船上卸载之后就可以直接装上国铁，这将大大加快运输效率（日本，国铁改革后也证明确实如此）。日本国铁在前期采用私有方案时，只关注了自己的利益和效率，舍弃了互通，也带来了效率的低下。 所以，在开发和交付微服务的时候，尤其是在多语言生态下开发和交付微服务，我们从一开始就要将互通性作为首要考虑因素，从而不会因为执迷于某些服务或者系统的单点效率而失去了整个微服务体系的整体效率。 图 1  多语言的微服务生态

微服务作为架构风格几乎成为云时代企业级应用的事实标准，构成微服务的技术元素本身却并非革命性。跨平台的分布式通信框架、地址无关的服务注册与发现、智能路由与编排等技术早已在CORBA、SOA时代实现了一遍又一遍，我们不禁好奇，微服务有什么不同？本文是对企业分布式应用的一次回顾，与前微服务时代相比，我们究竟在哪些领域吸取了教训，哪些方面持续搞砸。 架构的关键在于构造合理的封装抽象。良好的抽象构造如进程，由操作系统接管CPU调度、内存地址空间分配和I/O，程序员的心智从此解放，得以聚焦在业务逻辑上。糟糕的抽象往往引向万丈深渊，大量精力被浪费在抽象泄露带来的问题上。 让我们从组件间的通信开始，最初人们认为这只是需要被解决的技术要素。关于如何实现跨平台的分布式通信，30年前诞生的CORBA架构在今天来看仍然非常漂亮：通过定义IDL/ORB/API我们可以将内存对象任意分布于网络中。只要共享IDL，对象可以由C++/Java等不同的语言实现，其互相调用就像本地方法一样简单。然而实践经验告诉我们，分布式系统总是会出现本地调用不会发生的各种问题：网络的开销、传输的延迟、消息的超时和丢包、远端系统的崩溃……物理世界的技术约束是无法被忽略的，我们没有办法把分布式调用抽象成简单的本地方法。因此Martin Fowler在他的< 企业应用架构模式>里提出了著名分布式对象第一定律：“不要分布式你的对象”。相反，你应该把尽可能多的操作置于进程之内，通过replicate整个应用的方式来实现系统的scale。 由分析师们发起的SOA运动从另一个角度看待这个问题，Web Service应该是对企业资产和业务能力的封装。我们开始站在更高的维度，远过程调用不再只是技术意义上的集成。WSDL不仅是通信调用的接口，更是服务间的契约；UDDI不仅是服务描述、发现、集成的中心，更是企业业务与服务的黄页。WS-*在厂商的裹挟下发展成包罗万象，却也没几个人能掌握。开发者们抱怨花了太多时间写冗余的XML制定所谓的规范，WSDL生成的客户端也将不同服务耦合在一起。是否有更加轻量敏捷的方式，让我们快点开始写第一行生产代码？ 于是我们看到REST的兴起。起初是作为反叛，用更加轻量级的方式(http+json)使用Web。然后我们发现”企业级”应用并非需要ESB这样昂贵的专有中间件，由”消费级”技术组成的万维网是世界上最大规模的分布式网络，我们应该向其学习如何构建健壮、可演化的系统。Roy Fielding那篇论文所提出的无状态、可缓存等特征已经深入人心，而狭义上的REST API(基于资源的URI、HTTP动词和状态码的标准接口)也成为API设计的最佳实践。 既然API和网站一样都是基于通用Web技术，API是否可以像网站一样作为产品提供呢(APIs as product)？于是越来越多的企业开始将自己的业务能力封装成API，提供给消费者，随之而来的是更弹性的商业应用和更灵活的计费方式。很多组织也着手构建自己的API市场，把内部IT能力整合、复用，并为孵化外部产品做准备。API已经成为商业价值主张的一部分。 我们从聚焦实现细节的rpc出发，来到了更具价值导向的REST API。即使构建内部系统，以消费者驱动的方式，也总是能帮助我们设计出更加松耦合和易于演进的API。 编程语言中的组件构造(如Java中的jar, C#中的dll)是软件架构师们封装可复用单元的最常用武器。组件作为理论上的最小部署单元，在工程实践中却并不容易独立变更。一般应用程序需要讲多个组件打包成一个部署单元(如war包)，链接在内存地址中进行调用。对单个组件的热更新往往对组件间耦合和对象状态管理有很高的要求，重新部署整个应用一般是默认选项。以进程为边界构建可独立部署的服务成为架构师的另一项选择。 早期的服务只是单纯的技术构件，大多数组织从纯粹的技术实现角度考虑服务的划分。SOA的推动者们指出企业的信息资产应该被复用，信息孤岛应该被打通。通过将不同的服务编排组合，我们应该能够实现IT对业务更加灵活的支撑。SOA的服务建模一般采用业务流程驱动的方式。一个典型的SOA设计是由业务分析师自顶向下地对企业现有业务流程进行分析，通过BPM引擎对流程进行建模，向下分解成组合服务，并进一步拆分成数据访问服务(很多可怜的SOA实现中数据的访问被拆分成不同的读服务和写服务)。然而这带来的问题是，服务跟服务间的耦合非常严重。当我的业务发生了变化，可能会需要修改很多不同的服务，涉及到多个团队的沟通和协调。在运行时层面，服务器间的通信非常频繁，用户在界面上的一次点击按钮，对应的后台多层服务间的级联通信。这给系统性能和稳定性也带来了巨大的挑战。SOA式的服务建模从分析型思维出发，却往往低估了分布式系统和跨团队协调的复杂度，导致服务拆分粒度过细。 微服务的名字常常让人误解，但实施正确的微服务粒度可能并不”微”。Martin Fowler与James Lewis在开创微服务定义的一文中已经指出微服务应该围绕完整的业务能力。今天我们在做微服务设计时，常常利用领域驱动设计中的Bounded Context来进行服务边界的划分。假设你的库存管理是一个独立的业务子域，针对库存的维护和操作应该被放到通过一个上下文和微服务中，由一个团队进行开发维护。多数业务变更都发生在上下文内部，不涉及跨团队协调。单个codebase内的重构和部署让发布更加容易。维护库存所需要的信息查询的调用多发生在进程内，更好的性能，同时无需处理额外的一致性问题。如今我们对服务的定义已经超越了技术组件，领先的组织已经在尝试将design thinking, business operating model应用到微服务设计中。 即使有了设计合理的服务于API，我们仍然需要与之匹配的工程实践才能将其顺利实施。 今天仍有很多企业使用集中式的应用服务器部署应用：开发团队将软件包构建出来，再统一安装到应用服务器中。对应用团队来说，这往往意味着漫长的反馈周期和痛苦的自动化。我们很早就推荐用Jetty这样内嵌式的应用容器部署软件，启动更快，测试环境更接近生产。one Tomcat per VM的部署方式虽然运行时开销较大，却是前容器时代隔离性最好的服务部署模式。Docker将这个实践更进一步，除了更轻量级的隔离，我们第一次可以将软件和所依赖的环境本身打包成版本化的artifact，彻底统一开发和生产环境。容器技术的成熟让我们可以将部署去中心化，开发团队可以独立部署一个服务。 数据库耦合是影响服务独立变更的另一重要因素。相比代码构成的应用软件，数据库schema更加难以变动。因为难以测试、难以兼顾性能优化和耦合的发布周期等因素，服务间以数据库集成成为臭名昭著的反模式。服务间的集成应该依赖封装好的显示接口，而不是数据库这种实现细节。我们应该在兼顾数据一致性的情况下，为每个微服务分配独立的db schema甚至db instance。如果说十年前数据几乎等同于关系数据库。如今数 据则可能呈现出各种形态：键值、文档、时间序列、图…我们完全可以采用更加合适的技术，以去中心化的方式进行微服务的数据治理。 即使将这一切都解耦，如果将交给一个集中的团队去实施，很有可能最终还是得到一个耦合的架构。这就是是著名的康威定律。康威定律告诉我们“设计系统的架构受制于产生这些设计的组织的沟通结构”。但同样我们可以将康威定律反转应用：如果你想达成一个目标架构，则必须对团队结构进行调整，使之和目标架构对齐。相比单体系统，微服务在运行时监控和运维所带来的挑战更大。”you build it, you run it”的DevOps文化成为必须。监控运维不再是Ops部门的事情，产品团队必须对微服务的整个生命周期负责。授权的去中心化自治团队是实施微服务的必要条件。 我们在很多方向的确取得了进展。但即使在微服务时代，很多问题仍然在轮回发生着，似乎我们总是无法吸取 历史 的教训。让我们看一看那些挥之不去的反模式阴云。 另一个挥之不去的阴影是ESB。ESB在将异构的应用wire在一起有着关键的作用。然而当越来越多的职责被加入：数据报文的裁剪转换、难以测试和版本控制的编排(orchection)逻辑、服务发现智能路由监控治理分布式事务等All in One的solution将ESB变成了一个可怕的单点梦魇。所以微服务发出了“智能终端哑管道”的呐喊：我们只是需要一个不那么智能的代理处理可靠消息传输，将灵活的逻辑交给服务本身去编配(choreography)吧。 于是在典型的微服务架构里，负载均衡、服务注册发现、分布式追踪等组件以Unix way的方式各司其职。然而在利益诱惑和特性竞争压力之下，很多厂商不断将更多的功能放进他们的中间件，其中为代表的Overambitious API gateways俨然要重新实现占据中心的ESB。如果API gateway只是处理鉴权、限流等横切层逻辑没有问题，如果API gateway开始处理数据转换和业务逻辑编排，你应该提高警惕！ 尽管行业在不断发展，但很多时候人们仍然沿用旧的思维，用新的技术去一遍遍重新实现这些旧的反模式。 你总是可以在技术雷达里追踪微服务的state of art，如今这个领域的前沿方向是什么，Service Mesh, Chaos Engineering, 还是Observability as Code？然而 历史 告诉我们，新的技术在解决一些问题的同时，也可能会产生新的问题。更糟糕的是，我们永远无法记住 历史 ，用新的工具更高效地重现旧日问题。 Technologies come and go, Principles stay forever。好在那些架构和实践背后的原则是经久不变的。从操作系统到移动应用都会需要高内聚低耦合的架构，任何软件开发都需要版本控制、自动化构建等实践。谨记这些核心原则、谨记软件被创造出来是为了解决有价值的问题，可以帮我们更好的借鉴 历史 的经验，理解和采纳新的技术。 文/ThougtWorks刘尚奇 本文首发于刘尚奇个人网站：