你的项目真的适合微服务吗？
最近几年微服务可以说是火爆了码农界，面试几乎多多少少都会问到微服务相关的问题，仿佛程序员不沾点微服务就OUT了。身边大大小小的公司或者团队都在进行微服务的开发及改造。 但是实际上，很多团队对于微服务并没有一个深入的了解。很多团队一上手就是微服务，但是却完全没有将微服务应有的特性给展现出来。微服务的低耦合，灵活发布等特性被整体项目给困得死死的。强行拆分，项目耦合严重。甚至可以说得上连最简单的一体化应用都不如。
微服务架构相较于一体化架构的优势
1.遇到性能瓶颈时容易造成资源的浪费
传统的一体化应用只能在负载均衡之后放置多个实例进行水平扩展。
举个例子：
一体化架构：一个商城系统中秒杀出现了并发的情况，这个时候，在不改变系统架构的情况下，代码级别的优化是有瓶颈的，这个时候必然需要加服务器，创建多个实例，这个是系统级别的。但是除了秒杀这一块，后台管理，商品，等功能完全不会遇到性能瓶颈，这个时候就会造成资源的浪费。
微服务架构：
而微服务架构在事先就会将秒杀单独布置成一个微服务模块或者放置在活动模块之中，那么当性能瓶颈来到的时候，我们只需要将单个服务进行性能扩展就可以了，对其他微服务模块没有任何影响，同时减少资源的浪费。
2.不便于异构
一体化架构：异构也就是采用多种语言进行开发，传统的单一系统在项目开始的时候就已经被某种技术或者语言锁定，造成了如果需要更改语言，我们需要进行项目重构。
微服务架构：每个服务的实现细节都相对独立，服务之间耦合较低，团队可以对每个服务进行评估，根据团队的情况针对每个服务选择最合适的开发语言以及开发方案。
3.交付周期拉长
一体化架构：一体化架构在应用的任何更改都需要构建和部署整个应用程序。构建与部署的时间相应的较长，不利于频繁的部署，阻碍持续阶段性交付。拉长整个交付周期。
微服务架构：微服务架构由多个微服务功能模块组成，如果某个功能需要改变，我们仅仅需要构建和部署修改对应的微服务模块。甚至可以短时间内多次部署测试。提高了开发效率。
4.故障级联
一体化架构：通常在没有做业务分离的情况下，一体化架构耦合严重，很可能一个小问题会导致整个系统的崩溃。
微服务架构：故障隔离，耦合较低，一个服务出现问题并不会影响到整个服务。同时由于微服务有断路器的存在，当关键服务不可用或者可用性不强时，系统仍然可以正常运行。
5.技术债务
一体化架构：技术债务是个很严重的问题，相信每个成型的开发团队或多或少都会遇到过相关的问题。随着时间的推移，人员的变更,前期为了项目的进度，省下的技术文档，单元测试，缺少注释。这一切，都将让后来的开发者进行买单，还债，当你修改一个功能时，会影响到意想不到的地方。
微服务架构：微服务架构极大的避免了一些不必要的技术债务的产生，各个微服务模块单一化的职责，每个服务明确的发布接口，使得业务的耦合降到了最低。同时，易于开发、理解和维护，也可以将债务降到最低。
综上看来，微服务架构确实很好的解决了我们传统一体化架构一些痛点。在原有的架构基础上进行了一系列的改良。当下，也有很多公司完成了从一体化架构向微服务架构的迁移重构。
但是，这里但是来了，任何事物都有两面性，微服务除了优点就是缺点。
推行微服务存在的一些问题
1.服务难以治理，技术天花板高
微服务会拉高整个技术团队的天花板，对团队的技术门槛也会要求很高。随着开发的不断进行，除了最基础的服务发现、配置中心和授权管理。团队将会在分布式跟踪、熔断降级、灰度发布、故障切换等一系列微服务治理场景中遇到种种难题。给团队带来了非常大的麻烦。往往定位一个小问题，估计会耗去很多时间，这对于项目时间紧，团队人员少是个不小的麻烦。准备天天加班解决原本不需要解决的问题吧。
2.微服务应用是分布式系统，由此会带来固有的复杂性。 本身上微服务就是一个分布式项目，分布式项目相对于单体项目通过语言或者进程进行调用，微服务必须处理消息响应过慢，甚至无法召回的情况。
3.难以测试 测试一个大型的微服务应用是一件很复杂的任务，测试一个简单的单体系统，我们只需要测试他的REST API即可，测试一个微服务项目，我们最起码要启动注册中心，网关，本身的模块，以及依赖的模块。对于测试带来了很大的不便。
4.微服务部署，运维有点吃不消 部署一个微服务系统以及相关的各项自动化组件，对运维实际上是一件很大的挑战，多个服务的配置，部署，扩展，监控。同时，自动发布（jenkins），对服务做容器化（docker），包括每个服务后续的数据库一系列。
那什么样的项目适合微服务呢?
1.产品已经稳定或者已经有明确的产品形态，明确产品的边界，因为微服务扑拓一旦形成，重构的成本超乎想象。
2.公司技术积累较为成熟，有微服务项目经验，开发较为便捷，开发者有足够的控制部署方法，并且高度自动化。
3.业务并发较大，并且集中在一个或者少量几个业务场景下，使用微服务可有效节省资源。
当满足以上条件一个时，其实就可以上微服务了，同时如果是准备技术积累的一些公司，建议逐步试点，然后以点破面，逐步在团队中推行微服务架构。也可以根据项目实际情况，剥离一部分业务做微服务。
以上是 你的项目真的适合微服务吗？ 的全部内容， 来源链接： utcz.com/z/517605.html
