故事纯属虚构，如有雷同请对 入座！
▲Figure 1 – A公司打车软件架构▲
老张仔细看了看后说：“目前我们的软件架构已经做了数据存储分离，并且把计算模块和存储模块都搬到了京东智联云上，用虚拟机来代替物理机。我们的计算单元也可以做横向扩展来应对高峰流量，架构已经很灵活了，那么现在面临的问题是什么呢
大李思索了一下娓娓道来：“我们现在面临的问题很多，我印象最深刻的大概有这几类：
一、发布困难：我们的计算单元和存储单元是需要分布在三个办公地点的六个团队共同合作，所以每次发布版本都会是一个艰难工作。需要高级别的管理人员来统筹发布计划，上次发布就是由您来统一指挥规划的。
一个模块的微小问题都可能会导致整个项目延迟，而现实中每个模块都会出现问题，所以通常要准备多轮回归测试来保证所有模块都没有大问题。上次就是小王最后合并进来的计费模块的代码居然影响了客户管理模块，然后大家拼命加班测试修复问题仍然延迟两天交付。
如果任何一个模块出现了问题，都需要整个应用一起调试，再发布上线。而每个新版本发布都会很困难，导致很多小问题的修复都要等很长时间。
二、模块之间依赖问题：很多模块都在一台虚拟机中运行，它们之间的依赖关系错综复杂。所以各个模块的启动顺序非常关键，必须十分小心地排列，而每次模块改动都可能导致启动顺序的更改。启动顺序的问题几乎每次发布新版都会有问题。
三、模块之间优先级问题：同样因为每个模块都在同一台虚拟机中运行，它们运行的线程优先级会变得非常敏感，需要非常小心地来设置优先级。否则在并发量大的情况下，互相之间抢占CPU资源会导致某些模块得不到CPU资源处理的情况。为了调整线程优先级，各个团队花了大量时间来测试和制定各个线程的优先级，但仍然不能在所有情况达到预期效果。
四、扩容难：在并发量大的情况下，某些处理单元可能需要扩容。那么扩容的机器上必须复制所有的模块。如果任何一个模块在扩容过程中出现问题，扩容就会失败。不需要的模块进行扩容本身就是一种浪费，并且增加了不必要的风险。
所有模块的数据都存在同样的存储节点中，使得计算节点和存储节点的关系变得非常复杂且难于管理。
五、难于维护：因为整个系统变得非常庞大复杂，各个模块的关系又错综复杂。现在几乎没有人能对整个系统的各个部分都了解，导致每次改动（新功能或者修复bug）都有可能直到最后才发现有没考虑到的情况，加剧了发布的延迟。如果再发生核心人员的离开，将会使这个情况雪上加霜。上次老金的离职就是个有力证明，他负责的模块虽然接替的人还比较熟悉，但是和别的模块的关系很复杂，结果是修复了一个bug，却引入了两个新bug。
综上所述，我认为必须改变我们的架构，让架构更简单，模块之间更独立，更易于维护、发布和扩容。”
“你说的这些问题其实我也意识到了，最近我正在研究微服务架构和各种微服务平台。”老张点点头表示赞同：“根据我初步的研究，如果想解决上述那些问题，就要考虑向微服务架构演进。微服务应该能解决我们的大部分问题并且能提高我们的生产力。我给你推荐一篇文章，你可以先研究一下，回头我们再细致讨论。”
微服务小白扫盲：《微服务的理想与现实》
大李听到老张的回答，一下子转忧为喜：“那太好了！我先回去研究研究。过几天再找您讨论。”
▲Figure 2 – 微服务架构图▲
“从架构图可以看出，基本上原来所有的模块都变成了松耦合的微服务，它们都可以进行独立部署、发布、扩容。所有困扰我们的发布难、扩容难、模块CPU资源竞争问题、模块依赖问题全都可以解决。这样我们每个微服务可以独立发布新版本，新功能的发布和bug修复的流程都会快很多。”大李眼睛闪着光，兴奋地说道。
“同时，独立部署后也不再需要进程管理模块，各个微服务也不必共享基础架构模块，可以根据自己的需要来选择技术。另外因为各个服务现在界限清晰，每个微服务负责的功能相对简单内聚，开发人员很容易理解单个模块内部逻辑，所以维护难问题也可以得到很好解决。”大李继续补充着。
老张的脸上露出了满意的笑容：“那看起来我们的问题都得到了解决。另外我们公司已经开始使用敏捷开发，组建了scrum团队，并且我们有了Devops的经验。所以三地的各个团队可以变成独立的scrum团队，负责独立的微服务，这样人员之间的协同工作问题也可以得到解决。那我们是不是可以立刻开始微服务化了呢
大李的眉头又皱了起来，难为地说道：“张总，虽然微服务化很好，我们肯定要朝着这个方向演化。但是微服务也会给我们带巨大的挑战。”
“嗯，天下肯定没有免费的午餐。”老张随即问道，“说说看，我们的挑战主要是什么
大李早已调研清楚，为老张一一分析：“首先，我们需要把现有的应用拆分成多个微服务。这是我们的业务内容，非常关键，需要我们自己慢慢来做。但是微服务架构本身有很多的东西，比如这张服务注册发现图，如果我们采用springcloud架构，我们集成后需要自己部署维护注册中心。而注册中心集群也必须是高可用的。如果我们自己来部署维护注册中心集群，那这就是我们的短板，因为我们没有eureka或者consul的专业知识，部署和后期的运维工作都将需要更多的工程师。这将大大增加我们的成本，我们的组织结构也会更复杂。”
▲Figure 4 – 调用链（来自jaeger官 ）▲
大李又打开了一张微服务 关的架构图，指给老张看：“另外一个就是微服务 关。我和团队讨论了，微服务化还是要一步一步来。先把不重要的服务微服务化，一步一步演进，随着我们不断学习，再把重要的模块微服务化。这样风险会比较小。所以我们需要微服务 关来把微服务化的服务暴露给没有微服务化的应用。例如我们可以先把通知服务微服务化，别的核心逻辑不变，可以通过微服务 关来调用微服务化的通知服务。这样我们又需要维护微服务 关集群了。”
扫码了解京东智联云 JDSF
大李眼前一亮：“好，我这就去研究一下。”
▲Figure 6 – 路由▲
有了这套方案，这样我们就可以轻松使用微服务架构来改造我们的应用了。”
大李兴奋地继续介绍他的想法：“这样我们整个架构就会演进到这个最终架构，这里面灰色的部分都是京东智联云JDSF帮我们做的事情。而我们只需要关注自己的业务逻辑就可以了。完成了这套架构，我们就能快速发布新功能，集中精力和D公司在市场上PK。”
你的公司是否也面临着大李和老张一样的问题一个非常复杂的应用需要快速快速响应市场，需要有动态扩容能力，而应用本身面临不能快速发布、难于维护等问题，进而不能适应需求时，就需要考虑微服务架构来解决问题。
但需要注意的是，微服务架构虽然能解决问题，但同时也带来了架构层面的复杂性，并且需要微服务基础设施的支持，所以也将为企业架构带来巨大的挑战。
京东智联云JDSF微服务平台正是为了满足微服务化的简单可行，而提供了基础组件以及服务治理、应用管理等功能，可以极大简化企业微服务转型并且规避架构转化中的风险。如果你也对JDSF微服务平台感兴趣，不妨点击【阅读原文】来试用吧。
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树服务 格(istio)ServiceMesh介绍8665 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！