# 在很多情况下规避盲目使用微服务架构
在16年的时候开始落地服务化架构在大中小项目落地，到现在遇到过很多次讨论，基本都是使用服务化技术，这里偏向于架构设计阐述，属于个人观点，供参考。
# 背景
依托于容器化的普及，Cloud微服务技术当前比较盛行，在以前应该是Dubbo服务，后来慢慢建立了微服务体系，注册中心，分布式配置等各类组件，后面Nefix组件有些开始不维护，再到AlibabaCloud组件，现在很多开源框架、培训机构等依然以这些做一些宣传点。然后从自己的在多个大中小项目和落地的情况，企业运营管理，跟进行业先进技术发展，后期运维效果等多个角度思考，这无形中也会引起另一方面的方向失误。
# 概述
服务化本身是解决以前旧项目大，更新迭代难，耦合度高，管理开发协助难，较难支撑大并发等问题，这个在大项目上简直是福音，特别是初步切入的时候，大家都感觉看到希望一般，对这个架构难得的喜欢。
在后来几代的微服务，从服务组件的不完善到目前国内外开源组件的健全，基本上技术架构和体系都已经不再是什么难点。然而在这两年接触到的其它团队讨论中，却把这个技术架构和方式带到了另一个极端，看到的景象一般如下：
- 每个项目都微服务，业务中使用微服务，为什么要上说不清为什么使用
- 项目超细粒化划分，确实拆分出来是好维护的，而且每个就一个职责
- 架构设计比较高大上，而且看起来很复杂，很完善，devops/容器化/自动化
- 常常要搭配上一些社区很多组件，每个组件都能说一大堆好处（不否认）
- 理论论述很全，组件化，分布式，高并发，消息中间件等名词很多
- 运维管理也一样是生态体系，prometheus/grafana/skyworking/elk等
- ……
无可否认，听起来确实解决了很多问题，云原生的生态体系也非常的全的，甚至刚毕业两三年的，都可以很快的学会这套体系的技术，之前遇到的行业都在微服务（这里指的是Java技术），针对自己的项目经验和接触到的情况，看到的可能跟以上的偏差会不太一致，包含有，有自己的思考方式，从几个点阐述：
- 技术是服务于业务能力上进行阐述，避免脱离业务谈架构
- 考虑是否需要这样的技术架构，解决的问题是什么
- 取长补短，新的架构是否可以解决实际问题和业务架构设计
整体思路偏向于个人经验和落地的思路，重点在于内部的落地，我有我思。
# 整个过程
这里过程从一开始的业务场景到选型进行阐述观点，即从业务场景，再到团队情况，架构设计，后期维护升级几个主线思路，这里主要以实际项目经验和实际案例为参考。
# 技术是服务于业务能力上避免脱离业务谈架构
脱离业务谈技术，这个是架构师大忌，无法落地的架构不认为叫架构。
每个业务的场景并不一样，然后需要实现的效果也不一样，在这个过程实际的讨论之后，才会选定解决方案和技术架构，当然这些是基础常识。
这里针对的是团队核心型业务讨论，业务从长远来看，对团队来说除了开发，还有运维，运营，战略产品等后期的发力点，并不仅仅是一个开发框架可以或者一种开发架构能解决的，这个过程至少要考虑到3-5年，其中隐性的就结果在开始的时候不会体现，在后面的时候才慢慢展现问题和架构规划的好坏，这里针对的是团队角度，而非末端执行角度。
从某个角度来说，一般末端对架构设计的理念其实并不是特别明确，执行层需要的是经验和能力，照着顶层的架构设计去实施即可，但是对于业务架构设计的人员来说，需要考虑业务的长久运营和管理规划，包括后期的行业发展跟进，架构的先进性和可持续性，产品性能力等等，以确保团队可以长久的运营下去和保持核心的竞争力。
微服务化可以解决一部分问题，但是不是能解决所有的问题，同时也会带来过程的复杂性和技术的复杂性，同步也包括人员技术的要求等，相对于以前单体应用来说，是一个利大于弊的。
这个过程很偏重于服务划分的颗粒度，服务划分的思考角度，服务的职责能力，服务的维护团队能力，当地团队的人才储备，行业或者说市场的发展方向，内部管理层的人员管理水平，技术消化能力等等，要不然容易形成为了技术而技术，然后整体服务化之后，丢在那里而相对于之前没有太大的提升和意义。
从核心业务角度考虑，服务化之后为业务带来什么，是复杂度还是维护，或者成本降低，解决了什么问题。
# 考虑是否需要这样的技术架构，解决的问题是什么
新的技术引入需求，需要解决业务的实际问题，避免盲目引入。
如果某个项目，或者试点项目，建议可以从几下几个维度进行项目结果进行判断。而针对于团队的主要业务或者项目来说，微服务化这类似的变革，一般要落地，更是需要整体公司的推动，整体意识的转变，1年算短的，3-5年算比较正常，这里的3-5年不仅是业务的建设，同时也包括团队的消化和成长，成熟期的判断，需要不断的注入项目进行历练，避免今天微服务，明天单体，对团队和企业的沉淀几乎没有。
在服务化之前，一定要结合业务和场景等，考虑好为什么使用。前期面试过较过的做微服务架构设计人员，在抛出一些技术和场景问题的时候，回应出来的效果感觉不怎么好，比如以下几个问题：
“业务只有几个服务，什么要拆分，拆分的思想是怎么样的，相对于以前有什么好处“
”使用cloud，但是nginx也可以解决为什么还要引入一层复杂的业务“
”项目业务并不复杂，并发的压力可以横向扩展，为什么一定要拆分“
“工程复杂，模块化拆分和开发也可以实现，分开不是还增加分布式事务复杂性？”
“……”
接收到的回应都是五花八门了，有些可能有偏向于执行端有些偏向于技术尝新等，有些可能不了解上层的考虑（比如架构）等，但是从技术设计的角度来说，基本上看到是有些偏悲观的，可能更多的类似于听到的更多的组件化，高并发，易于维护，模块化拆分便利，互相不影响，后期升级便利等等，但是怎么样去组件化，怎么样好维护，拆分就一定方便么，增加的成本怎么考虑，后面说不清如何为业务服务。
# 技术架构的提升，需要很多考虑点
主流技术并不是代表就是符合。
取长补短，新的架构是否可以解决实际问题和业务架构设计 技术并不代表就是一定要那个样子，其实还可以这个样子，没人说微服务一定要cloud或者alibaba，或者nacos。
架构和业务设计尽量从简化，同时解决业务项目中的痛点和后期维护等考虑，这里提几个点，如果项目和业务来在考虑和设计提升，建议可以考虑：
- 设计的服务中能不使用分布式事务就尽量避免使用
- 把不需要的东西去掉，比如依赖n多的外部所谓好的组件
- 把层级关系尽量标明，调用关系尽量要明确
- 工程划分以业务标准为主，职责明确，模块为主，尽量少的服务
- 涉及到互相依赖的包问题尽量减少，耦合关系要明确
- ……
如果你有过程体验和感受，上面的设计就偏向于宏服务的设计思想，但是并不代表它就有标准，这里没有所谓的标准，如果非要定义一定，自己的理解，符合你的场景的那就是标准，至于使用什么技术，这个相对比较多，也比较成熟，就不过多阐述。
不过有一点滑稽的逻辑是，可以使用微服务架构来实现宏服务架构，类似于以前提到的可以使用微服务架构实现中台服务架构，只是一个架构思想的提升，类似于可以使用单体技术实现微服务架构，工具和架构融合，提升业务。
更推荐根据项目和团队等实际本地的情况，使用单体+业务+微服务架构优势的整合，类似架构如宏服务，但实际深挖远仅宏架构那么简单，一些互联网的名词出现，深挖会发出它会解决掉一些场景和方向，类似于以前的关系型数据库一样。
取长补短，来获取到符合实际业务的架构和方案，得出最优解。
# 总结
并不否定微服务技术，这里是不建议你盲目使用微服务，微服务技术已经有很多年，在架构设计和技术方向上，不要盲目推崇使用被技术绑架思维，而是在了解之后，以技术解决我们的痛点问题。
以实际情况为主，以团队实际能力为主，以项目实际运行情况为主，在以前没有体系之后，依然也是可以有技术方案可以实现，使用springboot/nginx/k8s一样也可以实现类似的效果，只是看项目大小还有运维管理的成本。
不希望动不动上来就是一套体系，一套方法论，而是针对问题的痛点，去选择合适团队的技术选型和技术方案，并不是方案有多优秀，而是方案有多适合，这是架构能力的体现之一。
以上为微服务技术使用的一些看法，希望可以给不一样的参考和建议。