台湾のアリ戦略的思考と実践的なアーキテクチャ「の研究ノート
4.3 2018年8月2日午後10時01分18480個の単語4114 57件のコメント7つの同類鑑賞1を読みます
背景
最近建設段階で本格的に同社は、さまざまなビジネスユニットは、登場開発計画の鍵を知って熱望してステーションに、企業のITインフラストラクチャの著書」道の変換を見て喜んで比較し、問題を解決するために - 台湾の戦略的思考とアリアーキテクチャの戦闘は、「次の二つの単語を誘致するため、台湾のタイトルでなければなりません -
感触
友人と最近のチャット、本のプレゼンテーション、マネジメント研修を聞き、最大のゲインが実際に変更することを考えている、パラダイムシフトがより明確に多くのことを見ています。アメージング洞窟ショックの中への旅。、この感覚他の人が関わっ見てより多くの幸運であり、いくつかは通過している、といくつかの経験の程度でよい、うまくいつか上記のプロットは気持ちを拡張感じながら、内部のアーキテクチャの進化の多くは、長い時間を読んだ後落ち着いてすることはできませんそれは素晴らしいです〜
学びます
1.台湾でアリの起源は、世界で最も成功したモバイルゲーム会社のスーパーを訪問する非常に興味深い戦略、アリの幹部は15年で、同社が開発したこの典型的な小さなチームモデルは、ゲームのクローズドベータ版の最速の打ち上げであってもよいし、不人気、すぐにチームが失敗した後、だけでなく、罰することができなかった、新製品、介入中のほとんどの管理の役割を促進する試みを放棄することができ、さえ式典が、彼らは失敗から何かを学んだ記念して開催されます。そのコア競争力は、駅の機能であるゲーム開発の年間の科学研究の方法およびシステムを、蓄積してきました。だから、多くの模倣者が交換することはできません。
ベトナム戦争にユニットとして大隊を戦うために;第二次世界大戦、戦うためにイスラエル軍のユニットの間に2米軍の中東への戦いに7人、または非常に小さいクラスの行の11人に戦って、今日は最も柔軟性があります軍事組織だけでなく、コア競争力と組織の最強攻撃能力。米軍は非常に強力なミサイルコマンドシステムがあるので、前方のような小さなチームを置くことを敢えて、柔軟に戦うことができた判断を行う、との戦いをリードし、迅速な小さなチームをサポートするために、台湾で非常に強力な能力を持っています。ました
米国は、図を戦います。
3.製品の優秀さ、共有お店、デザイナーシェアの共有思考の名前は、食物連鎖を共有します
シェアショップ、手頃な価格の商品の爆発モデルを構築するためのビルダーの後に名前を持つ製品の優秀さはすぐに魅力的、伝統的な衣服産業ショップ事業の多くは大幅に限界費用を削減、Mingchuang協力、お店のシェアで買い物をするのに最適な場所を取りました。
シェア設計者は、レコードの名前は、多様なデザイナーの設計プラットフォームを構築するために、設計者が保持することができますが、自分のデザインがMingchuang協力に来て、1回のバイアウトの著作権または注文配当によっては、とき、設計の専門家が多数集まります生態系の構築の一連の後に良い、名前が共有食物連鎖を共有し、より大きなステップを作成するために始めました、
共有生態系、ショップに参加するには、世界各国、世界中の、統一されたトレーニングマネージャー、出荷供給、在庫、グループ統一培養による分布、店は一通りの名前を作成するために投資する必要があります。およそ千億850億、海外からの現在Mingchuang販売。
クラシックケース
アリババは、淘宝網とTmallビジネスをサポートするために、この時点で淘宝網、淘宝網の技術チームと歩調を合わせていない長い猫の日前に、2008 Lynxの部門で設定2003淘宝網部門、年に設立されました。
この組織構造の形成は、技術チームは、淘宝網のビジネスニーズを満たすために優先権を与える決定した真剣リンクスの事業開発に影響を与え、Lynxのビジネスチームの訴えを作り、（私たちはすべてを知って、お尻を頭に決めました）。
別のビジネスアーキテクチャレベルの問題：淘宝網とTmall電子ビジネスシステムは、2つのシステムから完全に独立しているが、同時に、その上の商品、取引、評価、同じ機能の支払い、物流、が含まれています。
初期の淘宝網とTmall
上記の二つの問題を解決するために、2009年には、「共有部門は」されて入ってきた、淘宝網の技術チームからの主要メンバー、および淘宝網、Tmall同じレベルの組織構造（上図のように）前に、グループは、このような期待していますより良い淘宝網とTmallの両方のビジネスをサポートするための優れた技術チームを作るための方法、およびコーミングや降水行わ事業の2の電力会社、部門を共有するための一般的な、一般的なビジネス機能の降水量の2つのプラットフォーム、重複やメンテナンス機能、技術的資源の合理的な使用を避けます。ただし、次の開発が裏目に出ます。部門と淘宝網、組織構造のTmall同じレベルを共有しているが、ビジネスへの理解と貢献度に、淘宝網とTmallが話をするより多くの権利を持っていることは明らかですが、結果は2つのビジネスユニットの亀裂内の共有部門です。生き残るために。
これは、共有の開発部門とほとんどの人は偉大な偏りを持っていることを期待しています。
チームメンバーがどのように再び残業をしても、共有部門は、それがタイムリーかつ思慮深いサポートの良い2つのビジネスユニットに困難であり、固定リソースの場合には、ビジネスサポート淘宝網とTmall高圧状況と会い、ビジネス部門は、の結果であります学生のシェア部門内部は、言うことだけでなく、サイレント涙を苦しみながら、株式部門の満足度は、高いものではありません。
2010年にはそれが費用対効果の高い一緒に登場しました。ちょうど1本のライン上のポリ費用対効果の高いプラットフォームは、それが魅力の強い流れを示すだろうので、私たちは時間のために、彼らは費用対効果の高いプラットフォームを突き合わせてい急ぎます。
后来1688也参与其中，三大电商运营人员各展所长，争占聚划算平台上的有利资源，面对如洪流般的业务对接需求，当时刚成立不久的聚划算团队应接不暇（图）。
这时，集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享事业部！正是有了这“点睛之笔”，共享事业部便有了一个极强的抓手，将原本与三大电商平台对话权不平等的情况拉平，这使得“共享事业部”成为了阿里巴巴集团的核心业务平台。
从2009年开始建设的“共享事业部”为阿里巴巴的架构转型奠定了基础。
2015年年底，当大多数企业忙着进行年度总结和规划时，阿里巴巴集团宣布全面启动“中台战略”，构建符合DT时代的“大中台、小前台”组织机制和业务机制：作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场；中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务进行强力的支撑。
收获
烟囱式架构
早期淘宝天猫1688三套电商体系架构完全独立，各自应用独立运维和开发，三座“烟囱”分别矗立支撑着当时阿里集团最为核心的电商业务。
原因：
1.开发团队思考的电商模式不同，需要独立建设
2.新业务团队认为在之前基础上搭新业务会有太多的技术和业务的历史包袱，还不如重新构建
弊端：
1.重复功能建设和维护带来重复投资
2.打通烟囱式系统间交互集成协作成本高昂而比如订单信息 用户信息不得不打通后获取全局会员及消费数据
3.不利于业务的沉淀和持续发展
专家的养成
我们从小学开始学习很多基础知识，更多的是知识点的掌握；随着我们掌握知识点的增多，我们开始有意识地将一些知识点组合在一起，解决一些复杂的问题，关联这些知识点的过程实际上是将这些相关的知识点串成了知识线；随着在知识领域的继续积累，越来越多知识线的汇聚，我们有机会更全面地了解到这一知识领域（知识面），从而构建了对这一领域自身的知识体系，而这时的你相信已经成为这个领域的专家。
可以看到上图中共享交易事业部对于不同业务中交易场景的支持，1688（B2B）淘宝（B2C）天猫（B2C)的各自业务架构师对各自负责的交易流程的业务会非常的精通，不过在某种程度上看到的都只是哥哥业务场景中对交易业务的点，而图片下方的交易中心中的业务架构师所接触的来自不同业务模式下的所有交易相关的需求，这样的阵型是的负责交易中心的相关人员更容易扩展到线和面的维度全面掌握交易的业务。结合上面的理论，共享服务体系能很好的培养出特定领域的专家。
专人做专事？
整个技术团队作为一个组合精密的流水生产线，源源不断的业务需求涌进这条生产线后团队各司其职的人员协同配合，争取最快实现业务需求的满足。优点是可以不断打磨梳理出一套合理且高效的组织架构，但是弊端也会使流水线上的不同角色人员的技能的持续提升会出现发展瓶颈，做了3年开发跟做了5年开发人员可能在开发能力上灭有太大的区别，根本原因就是这两年的差别仅仅是用自己熟练的技能多生产出几个不同的系统。
业务架构师
业务架构师是共享服务中心发展的领路者，也是保障服务中心核心业务保持业务通用性和公共性的最重要捍卫者，能力模型是典型的即懂技术，也对负责的业务领域有相当理解的，通过共享技术的不断沉淀让部门从企业中的“业务支持”的组织职能，转变为基于企业核心业务和数据运营的团队，这个团队会更快更好的支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代，这种人才的价值将成为公司最宝贵的资产。
业务架构师一般会一直关心和思考以下问题：
1.当前的业务流程设计中，我依赖了哪些应用，哪些服务？
2.整个链路的依赖路径是怎样的？哪些服务对当前业务处理来说是最为核心的？这些依赖如果出错，会有什么影响？
3.一次业务请求处理的时间到底花在了什么地方？是因为某一个服务耗时很长，还是因为某一个数据库的访问操作自救，需要清晰直观的定位
4.我所负责的业务链路中，过去一段时间哪些服务是出错率比较高的，哪些服务是业务链路的处理瓶颈。
中心化与去中心化
中心化ESB企业服务总线实现的SOA方案根本诉求是实现异构系统（自研应用，商用套件应用，定制开发应用）间的交互，降低了系统间的耦合，更方便高效的实现了对新系统的集成。
弊端“中心点”带来平台能力难扩展问题业务响应慢，由于需要跟企业总线多次交互，对总线的访问和计算压力都很大，以及潜在的“雪崩”影响
去中心化分布式框架除了对SOA特性的实现和满足外，有效的避免了中心热点，雪崩等弊端。
共享服务化中心设计原则
1.高内聚，低耦合原则
2.数据完整性原则
这个原则与“高内聚，低耦合”一脉相承，是把这个思想穿透到数据模型层面，因为服务化架构一个很重要的业务价值就是数据模型统一。这里特别强调大数据的思维，不光只是业务逻辑的关键数据，还要考虑到业务的相关性数据；不光是实时在线数据，还要考虑到离线计算的数据。
3.业务可运营性原则
服务中心首先是从业务出发，单纯的技术层面抽象出来的服务框架一般不作为一个可运营的服务中心。期望服务中心是承载业务逻辑，沉淀业务数据，产生业务价值的业务单元
数据分久必合合久必分
尽可能水平拆分
1.基本拆分 主从同步读写分离
2.水平拆分 基于ID进行hash取模方式实现
3.异构索引表 降低全表扫描
精卫同步
可图形界面配置化一站式同步全链路监控任务调度平台
多条件频繁查询引入搜索引擎平台
采用异构索引的方式在实战中基本能解决和避免90%以上的跨join或全表扫描的情况，是在分布式数据场景下，提升数据库服务性能和处理吞吐能力的最有效技术手段，但是对于多条件频繁搜索则不建议异构索引，而是建议将数据同步至专业搜索引擎平台，入Lucene,Solr,ElasticSearch等。
异步化
1.业务流程异步化
对于有严格先后调用关系的服务保持顺序执行，对于能够同步执行的所有服务均采用异步化方式处理
2.数据库事务异步化
将大事务拆成小事务，降低数据库的资源被长时间事务锁占用而造成数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。
3.事务与柔性事务
传统事务
CAP 一个分布式系统最多只能在同时满足Consistency一致性 Availability可用性 Partition tolerance分区容错性这三项中的两项
BASE 是指基本可用（Basically Available） 柔性状态(Soft State) 最终一致性(Eventual Consistency)
一阶段事务 二阶段事务 比起一阶段提交，二阶段提交在执行同样的事务时会耗时更多时间，而事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量打到一定数量的时候，就会出现大面积事务积压甚至出现死锁，系统性能和处理吞吐率就会严重下滑
柔性事务
1.引入日志和补偿机制
事务日志记录事务的开始结束及参与者，参与者节点需要根据重做回滚记录到REDO/UNDO日志，当事务重试回滚时，可以根据这些日志最终将数据恢复到一致状态
2.可靠消息传递
要求消息至少投递一次，需要消费幂等
3.实现无锁
由于锁占用大量数据库资源，那么选择放弃锁也是解决问题的一种思路，通过其他手段保证最终一致性和隔离性
4.乐观锁
事务消息
柔性事务的思路，消息服务在其中扮演了事务日志的职能，对全局事务有一个统一的记录和调度能力，事务的参与者通过对消息订阅关系建立了事务间的关联。在采用消息服务实现分布式事务的场景如果出现异常时，一般会采用正向补偿方式，即不会像传统事务方式出现异常时依次回滚，会通过从消息的不断重试或人工干预让事务链路继续朝前执行，而避免出现事务回滚。
事务消息应用
事务消息回滚
总结：其实都不需要两阶段提交这样低效的方式来解决分布式事务问题，可以结合配合方案
1.应用程序一定要做幂等实现，特别是对数据库进行数据修改操作时
2.远程模块之间用异步消息来驱动，异步消息还可以起到检查点的作用
业务一致性平台
服务依赖链路众多，业务域数据不一致问题涌现，业务稳定性保障迫在眉睫，要解决这个问题，就需要实现业务处理的过程中，实时监测到业务不一致的问题，在消费者发现该问题之前系统就应该发出了报警，并且转交相关人处理。也许在用户开始投诉前，这个问题就被纠正过来了，这样影响面也就很小了。
目标：
1.高リアルタイムデータやエラー、汚れたビジネスロジックの実装を発見した技術サポート担当者を発見し、通知する最初のではなく、顧客からのフィードバックを待っています。
ビジネスルールの様々な2.便利なアクセス、各アプリケーションに素早くアクセスできますスクリプトで書かれたルール
3.改定ツール統合、プロセス仕様ダーティデータの改訂フォーム
新しいオンラインサービスを簡単にすることができ、ビジネスの4行上のリアルタイム監視を、検証します
実用的なモードを使用して、サービスの侵入を避けるために、変更は、変更ログデータ・アクセス・プラットフォームを実現するために、イベントの対応するサービスの種類、ルールの検査を置くためにイベント実行キューにメッセージサービスのデータをトリガします。イベントの種類や状態によって、ビジネスのチェックを行うには、ルールベースから対応するビジネスルールを得ます。
脳のマップを考えます
私の注意に小型の周りのギフトやジェーン・ブック