先週は、記事の更新[シークレットサービス]マイクロアーキテクチャは、着陸本当に小さなチームの練習をどのように分割するマイクロサービスのサービスをされた着陸時に求めて、多くのユーザーのプライベートメッセージを？具体的な方法はありませんか？一度、すべてのできますか？
まあ、我々は同社の製品は、インフラをアップグレード作る際に電気の供給を行う前に、だけでなく、他の同僚と、今日あなたと共有することを懸念している問題のために、より受け入れ、フィットネスや小さなチームの上に一緒におしゃべりし...の量はマイクロサービスの急速な下落を比較しました解決手続き。
注：より良い株があれば記事に提供分割方法は必ずしもすべてではありません全員の承認を得るには、あなたがメッセージを残すことができますああ~~~
I.プロジェクトの背景スプリット
チームで構成
UIデザイン：1人（他の専門的な製品設計にはありません）
フロントエンドの開発を：2
バックエンドの開発：5（高、中、低の一致）
テスト：2人の
運転・保守：あなたが知っている（などのバックエンドの開発の...）
事業概要
、市場で皆と同様に、多くの場合、電子ビジネスプラットフォームで使用され、ユーザーはPCの終わり、APPおよび第H5介して店舗に商品を閲覧し、他の公共の入り口、活動、注文、支払いおよび他のサービスに参加することができ、あまりにも多くの物語がありません！
システムモデルは、
以下に示すように：
第二に、設計解決スキーム
ビジネスロジックの分割に基づいて1、
閉じた共通の原則を遵守し、サービスの反復的な開発は、そのAPIは、消費者側には影響を与えません呼び出します。特に変更は、サービス障害が発生し、他のサービスに影響を与えます。
基準の条項に従って同定システムサービスモジュールは、各個々のモジュールが別個のビジネスサービスに分割され、各サービスは、その上に、独立して実行するように保証することができます。
それは非常に直感的ではないでしょうか？非常に単純な？我々は、すべての理由の事を知っているが、実際にはそれが問題になるのでしょうか？
这种基于业务逻辑的拆分虽然很直观但是由于团队成员对于各自的职责范围理解差异很大，往往会出现意见向左的事情，很难达到统一。
例如：把上图的电商平台第一种方案拆分为“商品”、“订单”和“用户” 3个服务，这样看也能把整个业务囊括进去。但是看看第二种方案，如下图所示：
如下图所示：
如图拆分为“商品”、“订单”、“用户”、“支付”、“广告”等6个服务，那么是不是更合理？那是否意味着拆分的越详细越好呢？
那就看一下“三个火枪手”原则！
2、服务拆分力度按照“三个火枪手”原则，1个微服务3个人负责开发。
就是说单纯的从业务逻辑角度拆分的话，很难判断服务的粒度。应该根据“三个火枪手”原则计算一下需要拆分的范围和数量，再确定合适的“职责范围”，避免出现拆分过粗或过细的情况。
并且3个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够根据每个人的技术能力对开发任务进行合理分工。
这么分析来看这样的搭配非常完美，但是大家都懂的很少有人力资源很充足的情况出现，不然大家就不会集体抗议 996了。不管如何尽量避免出现一个人维护一个服务的情况出现，因为有两个方面的考虑，第一，微服务是相对封闭的，里面是一条垂直的线，需要有专人去跟踪。如果一个人维护有哪几点不好？第一是力度过细，第二个是万一这个人今天请假了或者是生病了，甚至离职了，那总要有一个人backup吧，避免出现系统性风险。
3、基于可扩展拆分
将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，常变化和迭代的服务拆分为变动服务。
例如：系统中的用户服务、订单服务等不经常变化，跟业务关系不大，但又是整个系统最基础的功能可以划分为稳定服务。系统中的广告服务、商品服务等经常变更和迭代的服务划分为变动服务。
记住针对团队人力资源不充裕的情况，稳定服务可以拆分粒度粗一点，甚至可以放到一个子系统中。当然经常变动的服务业不要太细，不然维护不过来，会导致各个环节都可能出现问题。
4、基于性能拆分
这个不难理解，基于性能拆分就是将性能要求高的或者会发生高并发业务场景的模块拆分出来，避免发生压力过大影响其他服务的正常使用。这里不细说，因为和具体的性能瓶颈有关，影响因素过多，例如：服务器、数据库、缓存、网络等等。典型的业务场景就是电商的秒杀抢购功能，可以独立成一个服务 相应的资源可以多倾斜。
大家可以参考这篇：高并发服务器逻辑处理瓶颈，如何解决？
5、基于基础设施拆分
基础设施通常大家都忘记了吧，并且安排工作量的时候 很少写进工时里面的吧？领导也是看不见的工作量吧？但是可以说真正决定微服务成败的，恰恰是那个被大部分人都忽略的。系统落地后麻烦不断，简直就是坑中之坑，基础设施的建设也是考验整个团队的核心环节！
来看一下微服务的基础实施需要掌握哪些知识：
额。。。是不是懵了？这个小团队玩不转吧？！把这些搞完估计项目都黄了，哈哈哈！
虽然建设完善的微服务基础设施是一项庞大的工程，但是也不用看完后就放弃，或者认为自己是个小团队就不使用微服务了。虽然看起来很多但是目前市场上已经有成熟的开源框架直接拿来用的微服务基础设施。例如：SpringCloud，里面集成了服务发现、服务路由、网关、配置中心等常用的功能。再说了上面那么多基础设施并不是每个都是必须的，来来来我们划分个优先级：
1、服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2、接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
3、自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
4、服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。
根据优先级分析来看3和4两种是随着微服务节点数量的增加而越来越重要，前期拆分的服务较少并且团队对于微服务架构也在逐渐掌握中，可以暂时采用人工的方式，虽然效率低了点，但是不会因为某个环节熟悉程度不够而导致整体崩盘的情况。
三、经验总结
最后放上一张最终完成的系统访问交互流程图：
最后也写一下自己用微服务拆分改造后的一些经验吧，前期根据上面的拆分法则做架构改造还是比较舒服的，这里是真的舒服！因为业务更、代码、规范更清晰了，每个人的职责也更加明确了，特别是团队开发热情和积极性非常的高。因为从规划到落地的过程大家都成长了许多。但是这些还远远不够，由于职责、代码明确到个人，这样对于团队成员的学习能力也是很大的挑战。就拿学习能力来说吧，单体架构的时候可能只需要把自己开发的接口写好暴露出来就行了，但是微服务是从前到后的相关知识都需要学习，整体体系还是非常庞大的。
总之，微服务架构不再是一个人打天下的时代了，而是通过整个团队的技术综合水平来衡量了。发完搞 估计又有许多人私信说 只是理论罢了 没有一点实用价值，其实我也明白 现在很多人想要的就是 直接把源码地址贴出来就行了，直接down下来用。这里只想说洗洗睡吧！。
优质文章推荐
-
SpringBoot + ZK +ダボアーキテクチャ実践（D）：SB + ZK +ダボフレーム構造（Gitのソースアドレスを含みます）
-
SpringBoot + ZK +ダボアーキテクチャの練習（V）：マイクロサービスアーキテクチャの電気の供給を構築する（GitHubのアドレスを含みます）