微服务那些事儿 3.项目实战

第十章 三个典型系统案例

1.业务运营支撑系统

背景：EJB架构，运行十年多；业务量暴涨，几个月一个业务发展到一个月几十个业务；人员从十几个人的团队发展到几百人；数量几何级增长，海量数据。
现状：
1.架构老旧。EJB架构老旧。
2.系统庞大。系统没有引擎（引擎指的是什么？），全凭人堆（所有项目的问题，单从添加人员的方式去解决，是愚蠢的）。
3.业务复杂。业务逻辑复杂，业务间耦合严重，代码补丁多，可读性差，新人熟悉慢。
4.无法快速交付。功能开发、测试和上线慢；上线涉及功能模块多，导致上线过程复杂。客户的感受“慢”。
5.交付质量低。运维问题占用了开发人员的大量时间，导致开发时间减少，加班开发，恶性循环。
6.海量业务数据。已采用分库分表方式，未来数据量更大。
原因：主要原因，架构老旧。早年EJB是大型企业及应用的首选，拥有众多成熟案例，大而全的架构如今成了劣势、成了系统的瓶颈，而Spring项目虽然也会越来越大，但其可自由组合、随意增减、按需索取。另一个原因，业务复杂。业务复杂的同时还不断变化，当新需求的业务逻辑与以往业务不同时，要强行塞入原系统中，可能会破坏原架构的平衡。
不换架构的原因：在部署方面EJB有其优势，如集群部署方面；当时一直没有成熟的架构可代替，新需求的开发量有增无减，导致重构一直被拖延。但是现在微服务架构已经成熟。
解决方案：架构层面，微服务架构，Spring Boot + Spring Cloud替换EJB。
改造点：
1.将原有接口之间调用的SOAP方式替换为更轻量的REST方式；
2.将原有的消息队列实现方式JMS替换成分布式支持更好的Kafka；
3.将原来的数据库Oracle替换成HANA内存数据库，读写更快，突破传统数据库都会遇到的IO瓶颈。
步骤：
1.梳理所有的业务功能环节。通过数据模型和业务模型结合起来使用，对业务进行梳理，业务拆分方面，先按照业务环节进行粗粒度的拆分。
2.选取其中的一个业务功能，从上到下拆分，以金字塔结构展示。
3.梳理所有业务主体，进行归类，画出业务泳道图。
4.将金字塔结构图结合业务泳道图通过关键指标来识别关键业务功能（如，首先提取通过的业务功能为公共服务；业务主体是否为重点业务，保障高可用性，需要独立一个服务；长流程业务是复杂的业务，处理流程不同于其他业务，拆解独立......总之根据关键业务指标进行表示）。
5.进行重构。前后端分离的方式，只需要对后端重构。
重构步骤：a.业务量大，用消息队列方式进行处理，通过接骨法解除代码耦合，提供对外服务接口，便于后续上下游环节拉通；b.先拆解公共服务，其次是特殊业务主体服务，最后是不同渠道实现方式（这个是该EJB项目订单功能的独有需求，界面、接口两种调用方式）；c.某些业务环节涉及了大量业务主体，影响大，通过修路法，先建一个服务于原来的系统并行使用，同时分流几个试点业务到新的服务里，当上下游调用通过后，通过分批逃跑法，把其他业务都迁移到新的微服务上，直到最终废弃旧的模块；d.数据库的拆分工作同时进行。（该书对微服务架构下数据库的重构，并无太多论述）
（以上几点 参考第3章拆分方法，作者以订单业务做例子，尚不记录）

2.车队管理系统

背景：对车辆信息进行管理，所属企业拥有全欧洲数量最大的车队。
技术架构：Spring Boot + Spring Cloud；Yeoman JHispster Grunt Docker；Spring JPA；Spring Security等等
服务拆分：
考虑因素有，1.业务如何拆分；2.服务间如何调用；3.粒度选择
拆分方式，从无到有，从先到后的依赖关系来构建。即先把基础服务创建出来，后面的服务创建后就可以调用已有的服务。

1.财务管理系统

背景：财务管理的核心业务系统，架构老旧，运行几年。
现状：
1.项目团队50人，上线交付周期长。
2.与外围系统对接多，很大一部分业务仍采用人工方式处理，自动化程度低。
3.业务主体多，对应的业务规则多，导致业务逻辑复杂。
4.计算逻辑复杂，都用存储过程进行处理，数据库中存在几百个存储过程，且个别行数在5000行以上。
5.系统前端和数据库端的逻辑特别多，形成两头中的哑铃型结构。是种不健康的机构。
6.Java后台代码与存储过程有一部分逻辑相同，导致需要同时维护两套代码。
7.所有的业务主体都在一起处理，耦合严重。一个需求变更，需要改动的地方太多。
8.存储过程的可读性差，维护难度大，导致代码的维护十分依赖对系统熟悉的人。
调查原因：首先，技术架构老旧。其次，架构缺乏整体的规划，导致后期的失控。再次，对业务缺少规划，没有将属于同一类别的业务主体通过泳道进行隔离。没有考虑后期业务增加后的扩展性，面对业务主体的增加，不是进行分类，而是增加判断逻辑，导致前后端判断逻辑不断庞大、可读性差、维护越发困难。
解决方案：使用微服务架构重构。将哑铃式架构变成纺锤式，将业务逻辑从前端和数据库收回到Java后端。
技术改造点：
1.前端不在负责业务逻辑的判断和处理，只负责展示。
2.对存储过程进行改造
3.通过服务化，与外围系统对接更方便，达到提升自动化比例的目的。
业务改造点：
1.将业务主体进行分类，通过泳道隔离，业务主体间独立，互不影响
2.按照业务流转环节，拆解系统成为几个大的服务
3.业务复杂的规则逻辑，将其规则进行整理，抽取城规则服务
4.计算模块消耗性能，影响大，又是核心功能，不同业务主体都会调用，符合关键指标的标注，需要拆分为公共服务。由于其复杂，需要再向下拆分成更细粒度的多个公共服务。

第十一章 开发管理

微服务对于管理的要求比传统应用更高，若是项目管理做不好，使用微服务，治标不治本，还会出现失控的风险。以下针对项目管理中的开发管理进行概述。

1.管理原则

1.小，小团队易于管理，沟通成本低，交付质量容易控制。
2.线下，尽量不使用虚拟团队、远程协作。
3.分批部署，不要一次性太上多，容易排除定位出问题。

2.日常管理

每日早上一个站会，每日回答3个问题：
1.昨天工作的进展；2.遇到什么问题；3.今天准备做什么。
采取众议方式，组内多交流，形成知识传播，共同进步。

3.代码质量管理

1.不断优化；
2.持续改进；
3.通过复用来降低代码出错的可能；
4.精益管理和持续交付。
作者提议，让开发人员写概要设计，再由SA（System Analyst系统分析师）来审核。而非传统方式，SA做概要设计，所有开发人员根据概要设计进行开发，而导致过于依赖SA，时间上耽误。

4.工作方式

很多问题不出在工作本身，而是工作方式上。
1.相同性质的工作交由一个人做，如增删改查的功能，提高效率。
2.程序员不了解系统，可能会重写轮子，或者写出逻辑复杂的代码。要求开发前，每个开发人员先叙述思路，如何实现，参考了哪些代码，有何不同。
3.项目由计划，就需要按照计划执行，否则造成延期，用加班补偿。

5.BA的职责

Business Analyst 业务分析师。
职责：1.需求明确；2.业务的传播。
对于新的业务，BA可能需要向不同的人传达多次，重复性工作可做成视频。
工作内容：BA确认需求，开需求评审，让大家明确了解需求，需要让每个人知道做什么和为什么这么做；BA合理控制需求，随时了解排期完成情况 ，不能没有节制地接需求，和SA一起评估工作量；通过USER SOTRY将需求文档化，开发人员通过USER STORY明确知道需求的来龙去脉（可以包含往来邮件的内容）；通过JIRA管理需求，方便查找和维护。
（USER STORY是用户需求的简化表达，用一两句话表达完整的想法。作为 我想要做 ，以便<实现 zzz 的好处>。一条 User Story 只能有一个 User 角色。）

6.SA的职责

System Analyst 系统分析师。
职责：1.技术选型；2.框架选择；3.标准化工具；4.代码质量管理；5.审批概要；6.提供工具，帮助开发人员快速上手
工作内容：设计系统级别的需求要重点关注，考虑对系统的影响，分等级，做好跟踪，确保部署时不出问题；选择合适的技术框架简化开发难度，不要使用冷门的技术，使用主流技术，新人融入快；大团队人员多时，做的事比较独立，工具类可能无法复用，要求架构在整体层面不断抽取出狗聚类，进行宣贯（宣传并透彻理解），节省开发时间，尽量使用已有的工具。

7.DEV的工作原则

Developer 开发人员。
职责：1.先找轮子；2.找不到时就开发可复用的轮子；3.边开发边清理；4.边开发边写单元测试；第三方库慎用，强耦合的集成，代码渗透严重；5.尽可能增加代码，而不修改现有代码
要点：不仅要知道如何做，还要知道为什么这么做，可通过USER STORY文档的支持。经常对开发内容进行讨论，避免双方理解不一致的问题。